自動テストを Firefox でも行ったところ、不思議なことに Firefox でだけ失敗するテストがある。[cci]:[/cci] で行入力モードへ移行し、[cci]^V[/cci] でリテラル入力状態にした後、[cci]escape[/cci] キーを押して状態を途中でキャンセルするというものだ。そして、正しくリテラル入力状態がキャンセルされ、最後の行入力の状態から変化がないことをテストする。

これが Firefox でだけ失敗する。行入力バッファがクリアされてしまうのである。つまり勝手に空っぽになってしまうのだ。なにこれ。というかなんだこれ。

調べてみたところ、[cci]escape[/cci] キーを押されたことで発生するハンドラの中では、最後までバッファが勝手に変更されることはない。そのハンドラが終了した直後に勝手にクリアされてしまうようだ。つまり wasavi のコードがバグってるということではなくて、Firefox の動作がなんかおかしい。

もともと、wasavi 側ではキー入力ハンドラ内で 1ms 後に発生するタイマを仕掛け、そこで擬似的にバッファ変更イベント的なものを発生させている（これはインクリメンタルサーチで必要なのだ）。Firefox で動いている場合に限り、そのタイマの中でつじつまを合わせることにした。具体的にはキー入力ハンドラの最後にバッファの内容を data- なんとか属性にコピーしておき、タイマの中でその属性値と現在のバッファの value が違っていたらコピーしていた内容で復帰させるのである。もちろんこんな処理は本来は不要で、あまりに何をやっているのか意味不明なので、さすがにくどいコメントも付けておいた。

もしかしたら、このバグなのかもしれない。しかし件のバグは RESOLVED なので関係ないのかなあ？

とこのように、Firefox でだけ発生するバグを見つけると大変なのである。なにしろ拡張を華麗にデバッグするナウいデバッガがないので、古き良き…ではない古く悪しき printf デバッグでのたうちまわるしかないのだ。Firebug とかは、あくまで web ページのスクリプトのデバッガなので拡張は対象外なのです。

正確に言えば、最近の Firefox は Firebug ではないビルトインのデバッガを備えるようになっている。これが本当に最近の話だから困る。しかもそのデバッガが拡張をデバッグ対象にできるようになったのはさらに最近の話なので本当に困る。ちょっと実装するの遅すぎですよ。

ちなみにそのデバッガであるが、ステップ実行するのに 1 〜 2 秒かかったりステップ実行の単位がソースコードの 1 行ではなく副作用完了点的な何かなのか、複数回ステップ実行しないと停止行が進まなかったり、デバッガが動いている間 CPU を 80% 近く酷使してファンを全力全開にしてくれたり、まあなんといいますか、まだまだまったくもって人様にお出しできない状態なのだった。ひどいかひどくないかで言えば、かなり滅茶苦茶にひどい。

Firefox といえば OSS のブラウザの雄でであり、かつ長い歴史を持った老舗であるわけなのだが、デバッガ周りに関してなんでこんなにもあまりにも質の低いことをしているのか、ちょっとどういうことなのかよくわからない。どういうことなの。どういうことなんでしょうか。

SDK のドキュメントをつらつらを眺めてみると、HiddenFrame なるものを見つけた。これは要するに、バックエンド側で保持することのできる iframe のようなものらしい。HiddenFrame 内に構築される window はごくごく普通のそれであり、Audio コンストラクタも持っている。

そういうわけで、Firefox においては、HiddenFrame 経由で Audio 要素を得ることができた。子供の window で生成したオブジェクトをそのまま親の側で使用できてしまうのがかなり気持ち悪いが、たぶん、きっと、だいじょうぶ。

wasavi を実行中、音を出す場合がある。つまりビービー鳴らすモードを持つ vi と同様、必要なときにエラーベルを出す。もし「この音うるせーよ！！」と思われる場合は、ワークアラウンドとして [cci]:set bellvolume=0[/cci] とすれば、とりあえずミュート状態にはなる（例えばこの方がやっている方法だ）。将来的にはビジュアルベルに切り替わったりする気遣いをするかもしれない。

さてこの時に出す音は Audio 要素を使っていて、フロントエンド側で鳴らしている。音源は wasavi 起動時にバックエンドから送られてくる ogg または mp3 データである。

しかし、これは割と無駄なのではないか。複数のタブで wasavi を動かしているとして、各タブがもともと同じデータである音源のコピーを個別に抱えている状態だ。現状は 1 秒未満しか発音しないビープ音なのでデータ自体は数 KB だ。したがってものすごく容量を食っているというわけではないが、やっぱり無駄だ。

これを、Audio 要素をバックエンドで保持するようにして、フロントエンドで音が必要になったら発音リクエストを投げるだけにすれば、そういう無駄は解消できる。ということでやってみて、Opera と Chrome では思ったとおりになったのだけど、Firefox が問題だ。Firefox の Add on SDK 上のバックエンドは、Window ではない不可思議なサンドボックスオブジェクトがグローバルになっていて、つまり Audio 要素をバックエンド側で使えないのだった。

こういう場合、たいてい [cci]Cc[/cci] や [cci]Ci[/cci] といった Firefox 特有の黒魔術をごにょごにょして何とかなったりするものなのだが（Kosian では XHR や Blob や FormData についてごにょごにょしている）、黒魔術はしょせん黒魔術であり、あんまり使いたくない。なにしろ、AMO にアップする際の機械的チェックにすら「おい黒魔術使ってんぞ、気をつけろよな！」などと言われる始末である。禁止されているわけではなく、「気をつけろ」なのがミソではあるのだが。

さて、サウンドプレイヤについてもこの黒魔術を通して Audio 要素っぽいものを得ることはできるようなのだけど

var {Cc, Ci} = require("chrome");
var sound = Cc["@mozilla.org/sound;1"].createInstance(Ci.nsISound);
var uri = Cc["@mozilla.org/network/io-service;1"]
.getService(Ci.nsIIOService)
.newURI(self.data.url(...), null, null);

sound.play(uri);

これで得られる nsISound は Audio 要素とは全然異なるものであって、たとえばボリュームの指定とかはできないようなのである。