• [cci]disable-output-escaping[/cci] にいよいよ手を入れる。これは何かというと、XSL による変換を行う際にすでにマークアップされているであろう文字列をそのまま出力するというオプションなのだけど、Firefox が内蔵する XSLTProcessor はこれに対応していない。

  XSLProcessor へのオプションの与え方といったレベルではワークアラウンドはない、と思う。

  というわけでどうするかというと、マークアップ済みの文字列を要素の内容としてではなく、要素の data-doe 属性に収めて出力させる（doe は disable-output-escaping の略）。得たフラグメントをドキュメントに追加した後、querySelectorAll(“[data-doe]”) で抜き出し、それぞれを insertAdjacentHTML() で挿入させるようにした。

• xpi を生成するよう Makefile を追加した。生成物は https://github.com/akahuku/akahukuplus/tree/master/dist に置いた。ちなみにちゃんとインストールできるかはまだ試していない。

Add-on SDK で作る拡張機能のうち、バックグラウンドで動くコードはモジュールとして作り、複数モジュールを用意した場合はそれぞれが非干渉になるようになっている。そういう仕組みとして固定されている。モジュールの機能を呼び出す場合は明示的にエクスポートした関数を通す。

で、そのエクスポートされた関数を呼び出した際に不思議なことが起きた。Kosian を初期化するために RegExp のインスタンスを含んだハッシュオブジェクトをオプション群として渡す。その RegExp インスタンス、どういうわけか instanceof RegExp が真にならないのである。なので一部の初期化が正しく行われない。相変わらず恐ろしく重くて遅い内蔵デバッガで覗いてみたりする分には普通に正規表現オブジェクトだし、Object.prototype.toString.call() してみても [cci][Object RegExp][/cci] が返ってくる。しかしながら instanceof RegExp は偽になる。

なんか嫌な感じ。

ちなみにモジュール内の関数で生成した正規表現オブジェクトをその場で判定すれば当然 instanceof RegExp は真になる。モジュール間での関数呼び出しの際に引数が何か操作されてる感じなのだ。嫌だなあ。なんか嫌な、品のないブラウザだ。

またしても window と unsafeWindow の違い。Add-on SDK のコンテントスクリプトにおいては、window はおなじみの Window ではない不思議なグローバルオブジェクトである。ページのグローバルオブジェクトとしては unsafeWindow を参照する。なぜそんな殺風景な命名なのかはわからない。contentWindow でいいと思うのだけど。

• すでに何らかの動作にイベントリスナが結び付けられている時にそのリスナを呼び出したい際、リスナを直接呼び出すのではなく、コードから擬似的にイベントを発生させる手法をよく使う。リスナがスコープになくてもよくなるので。そういう場合、document.createEvent(…) して、init*Event(…) して、目的の要素に対して dispatchEvent(…) する。これが上手く行かない。init*Event() の引数内に view オブジェクトとして window を渡すとエラーになる。解法は window.unsafeWindow が存在する場合はそちらを渡す。
• CustomEvent に対しても同様。
• pushstate イベントをリスンしている。その状態で location.hash を更新すると Firefox でだけ pushstate イベントが発生する。どのブラウザで動作している場合hも、location.hash を更新するときは一時的に pushstate のイベントリスナを取り外すよう修正。

• favicon に、スレ画像から canvas を経由して動的に生成した data スキームの文字列を割り当てているのだけど。ImageData オブジェクトのプロパティにアクセスすると Firefox ではよくわからないが権限の異なるゾーンをまたいでるよ的エラーになる。そんな内部構造から来る制限でエラー出されても困りますよ。

  似たような不具合によれば、new window.ImageData や canvas のコンテキストの createImageData() ではなく、new unsafeWindow.ImageData() とすると動く。ふーん。

• CSS Transition を多用しているのだが、transition プロパティでショートハンド指定すると発生しない。transition-duration 等々で個別に指定すると発生する。なにそれ。まるで IE6 とかがやらかしそうなしょっぱいバグですけど……。

  それと、実際に確認したわけではないのだけれど、transitionend の発生するタイミングがおかしいとレポートしている blog の記事があったりする。本当ならひどいもんだね。

とりあえずここまで動いた。右の方の表示が変なのが悪名高き [cci]disable-output-escaping[/cci] だ。これをどうするか。

例えば続きを読んだ際に、最新のレス数を反映させたりする。それを行うには、簡単に言えば
レス
みたいなマークアップに対して、javascript で

document.getElementById('replies-total').textContent = '100';

などとすればいいわけだ。

しかし実際にはこの手のコードは赤福プラスの中にはない。実際のマークアップは
レス
などと binding 属性が付加してある。それで、汎用的な再バインド関数を呼ぶことにより、binding 属性に応じて自動的に更新させるようになっている。再バインド関数内では、バインドの接頭辞が [cci]xpath:[/cci] であればふたばのサーバが返した html をスクレイピングした結果の中間 xml からの xpath の結果、あるいは [cci]template:[/cci] であれば中間 xml をパラメータにして与えた XSL の変換の結果を用いて要素の内容を置換する。

この記事の話題はその、文書の一部分を更新するために呼ばれる XSL 変換だ。文書の一部といっても、変換に際して使用する一時的な文書は html 要素から始まるまっとうなそれである。つまり





とこんな感じ。この変換結果を、XSLTProcessor#transformToFragment() を用いて DocumentFragment として得る。

この時、返ってくる要素のツリー構造が Firefox とその他で微妙に違う。Presto Opera と Chrome は、DocumentFragment の子要素として body 要素の子要素を割り当てる。一方 Firefox は、単純に DocumentFragment の子要素として html 要素を割り当てる。

どちらが正しいのだろうか。正しさというのは違うか。そもそも ブラウザの javascript から利用できる XSLTProcessor のインターフェースは誰が考えて管理してるのかよくわからない。とりあえず Opera と Chrome の動作のほうが、そのまま単純に DocumentFragment を appendChild() の引数にできるので楽だし、何より多数派だ。一方で、動作としては Firefox のほうが素直ではある。body 要素を特別扱いします的な例外中の例外動作は何なんだろうか。DocumentFragment はあくまで断片なので html/head/body といった大物は対象にしない、みたいなルールがあるのかもしれない。しかし誰がその仕様を決めているのかよくわからない。

そんなわけで、得た DocumentFragment が body 要素を持っていたら、さらに body の子要素を DocumentFragment としてくくり出すようにした。くくり出す時に Range を使うのだが、これがちゃんと DocumentFragment にも作用するのか確証は持てない（DocumentFragment は Document のいわばサブクラスなので Range による操作も理屈の上では互換性があるはずなのだが、DocumentFragment に対する操作というのはけっこうどのブラウザも怪しい、あるいは怪しい時期があったのだ）。でもまあ、とりあえず動いているようだ。

function fixFragment (/*DocumentFragment*/f) {
var bodies = f.querySelectorAll('body');
if (bodies.length == 0) return f;
var r = document.createRange();
r.selectNodeContents(bodies[0]);
return r.cloneContents();
}


そんなわけで、Chrome で動かすのは割とすんなり行ったので、いよいよ Firefox 上で動かしてみるのだけれども。

やっぱり一筋縄では行かない。例えば、赤福プラス ver.3 以降というのはいろいろな場面で XSLTProcessor が大回転するのだが。XSLTProcessor に食わせる xml は、そのソースが最初にページをロードした際は body.innerHTML、XHR で続きを読んだ際はふたばのサーバが返す html そのものと微妙に違う。なので、それぞれがほぼ同じものじゃないとちょっと困るのである。そして、Presto Opera と Chrome の innerHTML は期待通りの動作をする。つまり body.innerHTML を参照したとしても、元のソース文字列に出来るだけ同じものを返してくれる。

が、どういうわけか Firefox の場合は innerHTML は勝手に属性の定義順を書き換えたものを返してくれたりするようなのだ。どういうポリシーがあってそんなことをしでかしてくれるのかはよくわからない。html から中間 xml を生成する処理の内容はすなわち、ソース文字列を正規表現でパースするのである。したがって属性の定義順が不定だとか、パターンで表現できる範囲を超えられるとちょっと困るのである。

現役の web ブラウザが複数ある中で、それぞれが得手不得手があるのは自然なことである。しかしあくまで個人的な感想ですが、Presto Opera に関してそういう場面に出くわした場合、「おうおうお前はこれは苦手なのかうんうんかわいい奴め」という気分になるのだけれど（Presto Opera がもはや現役ではないという事情もあるのだが）、Firefox に対しては「てめーこの程度のこともできねーのかよ！　何年 web ブラウザやってんだアホッ！」と思う。あくまで個人的な感想です。

Firefox の XSLTProcessor に関しては、以前の記事にあるように [cci]disable-output-escaping[/cci] が最大の障壁だと考えていたのだが、そこに至る前にもけっこうな壁があるのである。ああ。