LocationChange イベントのハンドラで、document に対して wasavi の起動と終了イベントをリスンさせているのだが、これはなかなかに乱暴だ。つまり、リスンさせっぱなしなのだ。

本来なら、タブが切り替わる直前に document からハンドラを取り除きたい。しかしそういうイベント（BeforeLocationChange みたいなの）はないようだ。LocationChange イベントは実質的に AfterLocationChanged だ。

したがってその結果、タブが切り替わるごとに同じイベントハンドラを何度も登録するというちょっと餡子の足りない動作になってしまっている。もちろん同一のイベントタイプ・ハンドラ・キャプチャフラグで何度 addEventListener を呼び出しても、登録は高々 1 度だけに収束するという DOM の仕様が前提なわけだけど。

Invoking addEventListener (or removeEventListener) repeatedly on the same EventTarget with the same values for the parameters type, listener, and useCapture has no effect. Doing so does not cause the event listener to be registered more than once and does not cause a change in the triggering order.

それと、現状では wasavi が終了すると共に [cci]passAllKeys = false;[/cci] しているのだけど、これだと wasavi に関係なく常にパススルーで動かしたいサイトで誤動作することになる。wasavi が起動する時点での passAllKeys の値を保存しておいて、wasavi 終了時はその値に復帰させるとかすればよいのだが、passAllKeys が実質グローバルなことを考えるとそれでつじつまが合うのか不安だ。いや合わないケースが確実にある。

この周辺をバグ報告されても、vimperator の仕様がそうなんだよーとおあしす運動（「おれじゃない」「あいつらじゃないの？」「しらない」「すんだこと」）を開始せざるを得ない。どうしよう。

対象ページの window は、content オブジェクトが持っているみたいだ。なので、content.document instanceof HTMLDocument のときにそれに対してごにょごにょすればいい。

なお前の記事では MutationObserver を使うつもりでいたのだが、なにか使い方を間違っているのか、要素を追加・削除しても一切ハンドラが呼ばれない。しかたがないので MutationObserver を使うことはあきらめ、wasavi 側で開始・終了時に CustomEvent を document に対して発行するようにした。このイベントを vimperator のプラグイン側でリスンし、適宜 passAllKeys を書き換える。

ところで気になるのは、wasavi を適当なタブで起動し、そのまま他のタブに切り替え、また戻ってきた場合。この場合、LocationChange イベントのハンドラで、wasavi が起動しているかを見て passAllKeys を制御することになる。しかしここで passAllKeys を直接触らざるを得ないのは vimperator の間違った設計だと思う。LocationChange 内で passAllKeys を触るプラグインが複数あったら破綻してしまう。ハンドラ側では passAllKeys = true としたい、というリクエストを出すだけにして、ハンドラの呼び出しが全て完了した後に呼び出し側でリクエストの有無によって passAllKeys を制御する構造にならないかな。

まあそれはさておき、とりあえず編集したいときに wasavi を起動して終わったら即抜けるっていう使い方をする限りは動くようになった。やったね。

そういうわけでいろいろ調べてみると:

• 言うまでもなく、vimperator/pentadactyl は Firefox の UI を限りなく vim に近づけるエクステンションだ。ちなみにググった限りでは、vimperator は Firefox を「vim みたいな Firefox」にするのがゴールなのに対し、pentadactyl は「web ページを見られる vim」にするのがゴールのようだ
• この手のエクステンションの宿命として、キーボード入力は誰のものかを常に意識する必要がある。web ページのスクリプトでハンドリングできる以上、本質的には web ページ上のキーボード入力はその web ページのものだ。vimperator のようなエクステンションは、web ページがキーボード入力を処理していない場合のみ成り立つ。wasavi はそれ自身が全てのキーボード入力を処理するので、当然両立し得ない
• vimperator 側では、liberator.modules.modes.passAllKeys に true を与えることで、vimperator の動作をスルーさせることができる。また、vimperator にはプラグインの機構があり、例えばタブを切り替えたときに任意のスクリプトを走らせることができる。プラグインは ~/.vimperator/plugin（windows 環境では %HOME%\vimperator\plugin）の下に置く
• wasavi がページ上に生成されたかどうかは、http://wasavi.appsweets.net/ をソースに指す iframe が存在するか、でとりあえず判断できる
• つまりプラグインとしてのスクリプトで、DOM の変更を監視し、wasavi の iframe が生成されたら passAllKeys = true にするようにすればいいはずだ。

ということでそんな感じでプラグインを書いてみたのだが、うまく行かない。document.body 直下に iframe が追加・削除されたかどうか監視するために、MutationObserver を生成し、observe() する。
ところがこれが失敗する。MutationObserver#observe() するには対象の要素への参照が必要だ。つまりまず対象のページの window への参照が必要だ。そんなわけでこんな関数を:

function getWindow () {
var wnd;
try {
wnd = liberator.modules.Buffer.focusedWindow;
if (!wnd) {
log('target window not found.');
}
}
catch (e) {
log('exception occured while retrieving focusedWindow: ' + e.message);
wnd = null;
}
return wnd;
}

LocationChange に引っ掛けたハンドラ内で動かすと focusedWindow を参照したところで例外が起こる。vimperator 3.5 のソースを見てみると

getFocusedWindow: function (win) {
win = win || config.browser.contentWindow;
let elem = win.document.activeElement;
let doc;
while (doc = elem.contentDocument) {
elem = doc.activeElement;
}
return elem.ownerDocument.defaultView;
},

で、つまり elem が null のとき while の条件節でエラーになる。そりゃそうですね。

うわーん
動かないよー
うーんどうやって window を得たらいいのかな……。

github で、vimperator や pentadactyl と共存させるとうまく行かないとの issue をもらった。そうなのか。

というわけでちょっと試してみることにしよう。しかし最初に告白をしておくと、これらのアドオンへの深い知識はまったく持ち合わせていない。というよりそもそも Firefox 自体のことをあんまりよく知らないんですけどね……。まあいろいろ調べながらやってみることにしよう。きっとどうにかなる。

タイトルには深い意味が込められているようであんまり込められてない。