GeckoのDOMイベント処理の実装

Text
GeckoのDOMイベント処理の実装

中野雅之
•肩書き
•正式: Mozilla Japan 国際化担当マネージャ
•非公式: Mozilla Japan 大阪支部長
•大阪の自宅で、自宅警備しながら仕事してます

中野雅之
•色んなアカウント
•メールアドレス: masayuki@d-toybox.com
•Skype: masayuki-nakano
•Twitter: @d_toybox
•Blog: 「もずはっく日記」で検索

アジェンダ
•DOMイベントの基礎知識
•Geckoのイベント処理の実装
•パフォーマンスを悪くしないためのヒント

DOM イベントの基礎
•フェイズと、プロパゲーション
•イベントを捕まえる
•イベントの伝播を抑制する
•ブラウザのイベント処理を妨害する

capturing フェイズ
•最初は window
•次に document
•root から target の親
•target の決定は、イベント依存
•フォーカス
•発生位置
•……等々

target フェイズ
•target フェイズは、 capturing フェイズの一部でもあり、 bubbling フェイズの一部でもある。
•window や document が target の場合も

bubbling フェイズ
•target の親から root
•次に document
•最後に window
•Event.bubbles が false の場合、 bubbling は発生しない

イベントを捕まえる
•書式:
•EventTarget.addEventListener( イベント名, ハンドラ, Capture?);
•EventTarget.removeEventListener( イベント名, ハンドラ, Capture?);
•イベント名: イベントの名前 "click" とか、 "keydown"
•ハンドラ: function foo(aEvent) { /* something */ } がお手軽で十分
•Capture?: true なら、capturing フェイズと、target フェイズ、false なら、target フェイズと、bubbling フェイズ

•単純な例1:
•全ての要素で発生するkeydownイベントを知りたい
•イベントターゲットより先に知りたい
•removeする必要はない
document.addEventListener("keydown",
function (aEvent) { /* something */ }, true);

•単純な例2:
•全ての要素で発生するkeydownイベントを知りたい
•イベントターゲットより後に知りたい
•removeする必要がある
function keydownHandler(aEvent) { /* something */ }
document.addEventListener("keydown",
keydownHandler, false);
…
document.removeEventListener("keydown", keydownHandler, false);

イベントの伝播を抑制する
•複数のイベントリスナを登録している場合、あるイベントハンドラで処理済みのイベントを他のイベントハンドラでは無視したい場合が考えられる
•Event.stopPropagation() か、 Event.stopImmediatePropagation() を呼ぶと、それ以降のイベント発生を中止できる
•Event.stopPropagation() では、次の EventTarget 以降でのイベントハンドラの実行を中止できる
•Event.stopImmediatePropagation() では、同じ EventTarget に登録されている未処理のイベントハンドラも含めて、イベントハンドラの実行を中止できる

ブラウザのイベント処理を妨害する
•ブラウザにデフォルトの動作(default action)を実行してもらいたくない場合が考えられる
•Event.preventDefault()を呼び出すと、 Event.defaultPrevented属性値がtrueになる
•defaultPrevented属性がtrueなら、ブラウザは default action を実行しない(ただし、タブの切替等、セキュリティ上、無視することはある)
•Web アプリは Event.defaultPrevented の値を、処理前に確認することで、Event.stopPropagation()の代用としても使える

Geckoのイベント処理の実装
•OS ネイティブなイベントを DOM イベントとして Web アプリに通知するケースを解説
•図にすると、次のように……

Geckoのイベント処理の実装
nsDocument
PresShell
widget
EventDispatcher
EventStateManager
Widget*Event
dom::*Event
PreHandleEvent()
PostHandleEvent()
Dispatch()
CreateEvent()
2
3
4
5
6
EventTargetChainItem
nsINode
EventListenerManager
HandleEvent()
handler2
handler1
nsINode
HandleEvent()
handler2
handler1
7
8
10
1
9

•イベントターゲットで、最初にイベントリスナが登録された時に、インスタンスが生成され、そのノードに保存される
•そのノードに登録された全てのイベントリスナを管理する
•HandleEvent() が呼び出されると、イベントの名前とフェーズ、イベントリスナのグループがマッチするものを探し、マッチした場合に登録されているハンドラを実行する
•stopImmediatePropagation() が呼び出されたら、中断する

モジュール間の処理の流れの例
1.widget/ は、各 OS のネイティブイベントをハンドリングするモジュール。ネイティブイベントが発生したら、内部イベントである、Widget*Event クラスのインスタンスをスタックに作成し、その値を設定する
2.PresShell にイベントを送信、PresShell が target を決定する

3.EventStateManager::PreHandleEvent() が前処理を行う
•詳しくは後ほど

4.PresShell が EventDispatcher::Dispatch() を呼び出す
5.EventDispatcher::CreateEvent() で Widget*Event のクラスに対応した、dom::*Event クラスを選択し、そのインスタンスをヒープに作成する
6.EventListenerManager を列挙した配列を用意し、 EventTargetChainItem::HandleEventTargetChain()を呼び出す

モジュール間の処理の流れ
7.EventTargetChainItem::HandleEventTargetChain() で、受け取った、各 EventListenerManager の HandleEvent() を実行していく
8.EventListenerManager::HandleEvent() は、そのノードに登録されたイベントリスナを順に実行していく
9.EventTargetChainItem::HandleEventTargetChain() が自身をもう一度呼び出し、デフォルトアクションの実行のため、System Event Group に登録されたリスナを実行する。

モジュール間の処理の流れ
10.EventStateManager::PostHandleEvent() で、デフォルトアクションを実行したり、関連するイベントを生成したりする

Widget*Event、Internal*Event
•WidgetEvent クラスが全てのイベントクラスの基底クラス
•WidgetMouseEvent や、InternalFocusEvent といった派生クラスが、イベントごとに定義・実装されている
•各クラスは、ほぼ構造体であり、メンバのカプセル化はほとんど行われず、メンバにダイレクトにアクセスする (読み書き問わず)
•widget から生成されるイベントは、Widget*Event、それ以外の場合は、DOM イベントのデータを保存するためだけのものは、Internal*Event と命名されている

Widget*Event、Internal*Event
•widget/
•widget/BasicEvents.h
•widget/ContentEvents.h
•widget/MiscEvents.h
•widget/MouseEvents.h
•widget/TextEvents.h
•widget/TouchEvents.h
•dom/events/
•dom/events/InternalMutationEvent.h

PresShell
•PresShell は、 Presentation Shell の略で、 nsPresShell.cpp で実装され、 nsIPresShell.h で定義されている nsIPresShell インターフェースを持つ
•ドキュメントに対し、一つ生成される (正確なところは不明)
•イベントの複雑な処理は EventStateManager、表示に関わる部分は nsPresContext に分離されている
•イベント処理では widget で生成されたイベントを受け取り、target の決定と、発火処理を行う
•PresShell::HandleEvent() や、関連メソッドを参照

EventStateManager::PreHandleEvent()
•PresShell がイベントを発火する直前に呼び出す
•マウスの操作によって変化する hover や、active といった要素の状態設定を行う
•マウスのクリックカウント等、状態の保存や、その値の Widget*Event のメンバへの書き出しを行う
•ホイールの速度等、設定でカスタマイズできる項目を、 Widget*Event のメンバの値を書き換えることで実現してる

EventDispatcher::CreateEvent()
•Widget*Event クラスのインスタンスや、 Internal*Event クラスのインスタンスから、DOM イベントの実装クラスを選択し、インスタンスを生成する
•Javascript の document.createEvent() の実装でもある
•EventListenerManager::HandleEventInternal() が最初のイベントリスナを見つけた時点で呼び出される

dom::Event
•DOM イベントの実装クラスは、名前空間 “mozilla::dom“ に、標準仕様と同じ名前で定義
•dom::KeyboardEvent、dom::WheelEvent 等
•nsIDOMEvent インターフェースを必ず継承している
•dom::Event は、WidgetEvent へのポインタを持ち、イベントの属性値はここに保存している
•DOM イベントクラスは、Widget*Event や Internal*Event へ、DOM からアクセスするためのラッパクラス

dom::Event
•古くから実装されている DOM イベントクラスは、固有の、nsIDOM*Event インターフェースも継承している
•新規作成時にはほとんど定義されない
•データにアクセスするだけなら、内部イベントクラスにアクセスする方が高速で、実装も単純化される
•nsIDOM*Event のメソッドは全て、virtual call になるためパフォーマンスが悪い

dom::Event
•内部イベントクラスを定義・実装する必要が無い、シンプルなイベントを実装する際は、webidlで定義したイベントから、実装コードを自動生成することも可能
•自動生成の定義は dom/webidl/moz.build で定義
•dom/bindings/Codegen.py によって、ビルド時に cpp ファイルが自動的に生成される

dom::Event
•実装例
•dom/events/
•dom/events/Event.cpp
•dom/events/UIEvent.cpp
•dom/events/WheelEvent.cpp
•content/svg/content/src/
•content/svg/content/src/SVGZoomEvent.cpp

EventDispatcher::Dispatch()
•PresShell から呼び出される
•最初に、 target の PreHandleEvent() を実行する
•window から target ノードまで辿り、作成されている全ての EventListenerManager を列挙し、配列に格納
•EventTargetChainItem::HandleEventTargetChain() にその配列を渡す
•その後、 target の PostHandleEvent() を実行する
•発火が終了しても、DOM イベントが JS の変数等から参照されている場合、内部イベントをヒープにコピーする
•発火処理後、スタックにある内部イベントは破棄されるため

EventTargetChainItem::HandleEventTargetChain()
•EventDispatcher::Dispatch() に呼び出される
•列挙されている、window から target の親ノードまでの EventListenerManager の、HandleEvent() を実行していく (capturing フェーズ)
•Event.stopPropagation() が HandleEvent() 実行中に呼び出されていたら、ループを中断する

•次に、target の EventListenerManager の HandleEvent() を呼び出す (target フェーズ)
•Event.stopPropagation() か、 Event.stopImmediatePropagation() が既に呼び出されていた場合、実行しない
•Event.stopPropagation()が HandleEvent() 実行中に呼び出されていたら、ループを中断する

•次に、列挙された、target の親から、 window までの EventListenerManager の、HandleEvent() を実行していく (bubbling フェーズ)
•Event.bubbles が false なら実行しない
•Event.stopPropagation() か、 Event.stopImmediatePropagation() が既に呼び出されていた場合、実行しない
•Event.stopPropagation() が HandleEvent() 実行中に呼び出されていたら、ループを中断する

•次に、イベントターゲットが生成した、CSS box を実装している、nsIFrame::HandleEvent() を呼び出す
• PresShell が EventDispatcher::Dispatch() に渡した callback クラス経由で呼び出し
•default action の実装に利用可能

•最後に、System Event Group のイベントリスナが登録されている場合、capturing、target、bubbling フェーズを再度、処理する
•通常の Web コンテンツからは登録不可
•Web コンテンツに Event.stopPropagation() 等を呼び出されていても実行される
•default action の実装に利用可能
•System Event Group 内のリスナで、 stopPropagation() 等を呼ぶと中断される

EventStateManager::PostHandleEvent()
•PresShell が最後に呼び出す
•イベントの後処理や、default action を実行
•マウスホイールによるスクロール処理やズーム処理
•mouseup から click イベントや、dblclick イベントの生成
•mousemove から、 mouseover、mouseout、 mouseenter、mouseleave イベントの生成

パフォーマンスを悪くしないためのヒント
•イベントリスナを必要以上に登録しない
•登録するノードが増える程、EventListenerManager のインスタンスの数が増える
•登録するハンドラが増える程、全てのイベントの発生時に、マッチするイベントを探すループの処理回数が増える
•stopPropagation()や、stopImmediatePropagation() を効果的に利用するとループを中断させることができる

•発火回数が多いイベントや、発火のコストが高いイベントはリスナを登録しないようにする
•EventListenerManager と、nsDocument は、一部のイベントリスナが登録されたかどうかをフラグで保存しており、これらが false の場合、イベントそのものを発火しないようにしている
•各フラグは、RemoveEventListener() でリセットされない。これは、RemoveEventListener() のパフォーマンスを悪くしないため
•発生コストが高いイベントは、一度登録したが最後、 document が unload されるまで、その document では発生し続ける

•mMayHaveCapturingListeners
•全てのイベントリスナが、bubbling フェーズのイベントのリスナであれば、false
•これが false なら、capturing フェーズのループは丸ごとスキップされる
•target フェーズのイベントは、bubbling フェーズのイベントリスナで取得できるので、target フェーズでイベントを処理したい場合は、bubbling フェーズとして登録する方が良い

•mMayHavePaintEventListener
•“MozAfterPaint”
•描画する度に発生するので、発生回数が莫大

•mMayHaveMutationListeners
•“DOMAttrModified”
•“DOMCharacterDataModified”
•“DOMNodeInserted”
•“DOMNodeInserted”
•“DOMNodeInsertedIntoDocument”
•“DOMNodeRemovedFromDocument”
•“DOMSubtreeModified”
•MutationObserver を利用するべき

•mMayHavePointerEnterLeaveEventListener
•“pointerdown”
•“pointermove”
•“pointerup”
•“pointercancel”
•“pointerover”
•“pointerout”
•“pointerenter”
•“pointerleave”
•“gotpointercapture”
•“lostpointercapture”

•mMayHaveTouchEventListener
•“touchstart”
•“touchend”
•“touchmove”
•“touchcancel”
•タッチデバイスを直接サポートする場合はやむを得ない
•利用しても他ほどパフォーマンスは落ちない(はず)

•mMayHaveMouseEnterLeaveEventListener
•“mouseenter”
•“mouseleave”
•“mouseover” や “mouseout” 発生時に、祖先要素全てで発生すべきか確認する必要があり、多数の要素上で、同時にイベントが発生する可能性もある
•“mouseover” や ”mouseout” で代用可能か、熟慮した上で判断を

•他にも細かい、イベント単位での最適化があるので、 EventListenerManager::AddEventListenerInternal()のコードを参照

•極端な話をすると、
•全てのイベントリスナを window に登録
•bubbling フェーズで登録
•Event.target を自前で確認
•Event.stopImmediatePropagation()で伝播を中断
•こうすると、イベントリスナを呼び出すコストは最小限に抑えられる
•もちろん、綺麗なコードになるわけではないので、やらない方が良い

最適化はほどほどに!

読みやすいコードで、
バグの少ないアプリを!

知っておいた方が良い用語・略語
•D3E
•DOM Level 3 Events
•ESM
•EventStateManager
•dispatch、fire
•(イベントを)発火する
•consumed
•preventDefault() が呼び出され、default action がキャンセルされている状態

その他の資料
•DOM Level 3 Events 仕様書 (Working Draft)
•Event developer guide (MDN)
•Adding a new event (MDN)
•dom/events (mxr)

GeckoのDOMイベント処理の実装

More Related Content

Featured

GeckoのDOMイベント処理の実装