近況報告たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。動向はもえじら組ブログで。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。Plusと組み合わせた状態であると書いてあり、やっぱり......と思いながら両方を入れてみたら確かに問題が再現した。ここまではよくある話。エラーが起こっている箇所はエラーコンソールのメッセージから容易に特定できたんだけど、でもどう見てもそこでエラーになるはずがないという箇所でエラーになっていた。具体的には1つ前のエントリに書いたcreateContextualFragment()の所。3.0.13でのテスト結果)。3.0.xや3.5では常にnullが返り、Trunkでは常に例外が発生する)ということだった。これは何かおかしいと思って、エラーコンソールに表示されるエラーをよく見ると、XMLのパースエラーで「属性が二重に定義されている」とメッセージが出ている。Plusのソースを見てみたら、怪しい記述を見つけた。オーバーレイ用のXULドキュメントで、idがmain-windowであるwindow要素のオーバーレイ内容にXML名前空間宣言が含まれている、というものだ。PlusがあってもcreateContextualFragment()が失敗しなくなった。それで、ここが原因だと確信が持てたということで、Bugzillaにバグとして報告してみた。Traversal-Rangeだったので、そこのバグとして報告してある。PlusのオーバーレイでXML名前空間宣言を書くのは本当のルート要素だけという風に書き換えるのが一番手っ取り早いんだけど......できれば本体(Gecko)の方を直してほしい所ではある。2005割と最近までMozillaには、あるイベントリスナを無効にするのにremoveEventListener()メソッドを使うと、他のイベントリスナまでも巻き添えに無効にしてしまうというバグがあった。拡張機能同士のコンフリクトの中でも最も厄介なトラブルは、これに起因するものだ。ウィンドウの読み込み完了時のタイミングで初期化処理を行うために、addEventListener()で初期化関数をloadイベントのリスナとして登録することがよくある。イベントハンドラは一つしか登録できないのに対して、イベントリスナならいくつでも登録可能だからだ。メモリの解放し忘れを防ぐために気を利かせて、この初期化専用のイベントリスナをremoveEventListener()で登録解除するようにしていると、冒頭の問題にぶち当たってしまう。ある拡張機能の初期化処理が行われたら、その次にイベントリスナとして登録されている初期化処理が行われなくなってしまう、ということが起こるのだ。Mozillaのバグだ。2005テストケースを見る限り、HTMLの属性としてイベントハンドラを定義しているケースについては対処可能のようだが、JavaScriptでイベントハンドラを追加している場合については対処不可能だ。――マニフェストファイルをいじって、セキュリティの制限を緩くするようにした。僕が把握してる範囲では、攻撃可能な穴はなさげだけれども、穴ってのは大抵、予想もしてないところから見つかるからなあ......まあその時にはその時だ。2005冗談じゃないっすよ。これを以て「Piroの作る物はやっぱ穴だらけだな」とか言われるだなんて。実装見たら明らかじゃないすか。Toolbarの横暴が原因ですよ。Toolbarの野郎、こともあろうにイベントハンドラそのものを上書きしくさりやがってる。こちとら可能な限り元のコードに影響を与えない方法を考えてあれこれ対策してるってえのに、そんな配慮のカケラもない。そんなの知ったこっちゃないね、俺様は天下のGoogle様なんだからFirefoxのコードを引っかき回したって許されるんだぜ、そんな驕りが窺い知れるってもんですよ。Toolbarが悪者だということがはっきり分かった。2005調べていて気付いたけど、これは、子タブについての扱いが、コードを書いた時期によって変わってしまっていることが原因だった。ある時期には「タブの要素ノードの配列」、またある時期には「タブのID文字列の配列」、またあるときは「タブのID文字列の配列をパイプ("|")で連結したもの」と、もー、バラバラ。JavaScriptは型チェックのない言語なので、こういうことがよく起こる。コーディング時に意識を高く保つ必要があるのが、JavaScriptの欠点といえば欠点ですな。2005タブのロックやなんかの機能が全然働かなくなっていたことに今頃気付いて原因を調べていた。Windowの影響らしい。Windowの変更が入ってからこっち、onclickその他のプロパティにアクセスしようとしただけでNS_ERROR_NOT_AVAILABLEのエラーが発生するようになってしまったようだ。返り値を取得できなくなってしまったことも痛いんだけど。xpcnativewrappers=noにしつつ完璧なセキュリティ対策を施せるだけの自信もないんだよなあ。投げ出したくてたまらんのだけど。更新すればするほど糞糞言われるしさ(自分でも言ってるけど)。2005普通にドラドロするだけでもタブのドロップ位置がズレたりしてたのでついでに直した。今の今まで放置してた辺り、いかに自分が普段この機能を使っていないかが窺い知れるというものですね。2005なんかまた違う問題がポロポロと出てきましたよ?タブを並べ替えたり消したりしてあれこれしてたらエラーが出るようになって、原因を探っているうちに、どうもタブの配列?がおかしくなってるらしいということに気がついた。gBrowser.mTabsはアクセスするとgBrowser.mTabContainer.childNodesを返すgetterになっていて、まあ、この二つは詰まるところ同じ物のように扱ってるんだけど、この、gBrowser.mTabContainer.childNodesが時々おかしくなるようだ。インデックスの範囲を超えた範囲の要素にアクセスしても、undefinedにならずに、要素ノードを返すことがある。見た目上は4つのタブが開かれていて、gBrowser.mTabContainer.childNodes.lengthを見ても要素の数は4と返ってくるんだけど、gBrowser.mTabContainer.childNodes[4]にアクセスしたら何故か要素ノードが返ってくる(本当はgBrowser.mTabContainer.childNodes[3]までにしかアクセスできないはず)。1.6の仕様変更に伴う挙動の変化ですか?とにかくこのせいで、nodelist[index]にアクセスしてundefinedが返ってくるかどうかで添え字がインデックスの範囲を超えてるか超えてないかを判別していた部分が誤判定を起こすようになってしまっていた。́・ω・`)並べ替え処理の前後でプロパティがどう変化しているのか......を調べようと思ってalert()でちまちまやってたら、なんか突然問題が起こらなくなっちゃったんすよね。プロパティの値を見ただけなのに?よくよく調べてみると、どうやら、getterになっているとあるプロパティに一度もアクセスしないままにタブを閉じると、そのgetterから正しい値を取得できなくて、エラーになっていたということのようだこんなのわかんねーよ!!ということで、タブを並べ替えた直後に一度だけgetterを参照してプロパティで正しい値を取得できるようにしたところ、問題の現象は起こらなくなった。2005原因なんとなく分かった。「最初のタブ」が全ての元凶。僕は普段、全てのタブを閉じた場合にはタブバーを表示しない設定にしていて、この設定では、一つめのタブを開いたり何らかのページを読み込むと、自動的に新規タブを開いて、入れ替わりに最初のタブを閉じるという動作になる。最初のタブはすぐに消える。問題が表面化しなかった。最初のタブを消さずにそのまま使い続けると、中途半端な初期化処理のせいで、色々と問題が起こる。