Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 1/248: 1 2 3 4 5 6 7 8 9 »

ツリー型タブとTab Mix Plusの衝突について調べていてGeckoのバグを見つけた - Aug 13, 2009

ツリー型タブが入ってるとスターアイコンからブックマークの内容を編集できない、という報告を見て、そんなバカなこっちじゃちゃんと動いてるのに!と思って薄々そうなんじゃないかなあと思いながらよく報告を見てみたら、Tab Mix Plusと組み合わせた状態であると書いてあり、やっぱり……と思いながら両方を入れてみたら確かに問題が再現した。まあここまではよくある話。

エラーが起こっている箇所はエラーコンソールのメッセージから容易に特定できたんだけど、でもどう見てもそこでエラーになるはずがないという箇所でエラーになっていた。具体的には1つ前のエントリに書いたcreateContextualFragment()の所。色々条件を変えて調べてみたら、どんな簡単なソースを渡した場合でもcreateContextualFragment()の返り値が常にnullになっているようだった(Firefox 3.0.13でのテスト結果)。で、さらに条件を変えながら色々試して分かったのは、そもそもツリー型タブと組み合わせなくても、Tab Mix Plusが入ってるだけでcreateContextualFragment()が全然使い物にならなくなる(Firefox 3.0.xや3.5では常にnullが返り、Trunkでは常に例外が発生する)ということだった。

さすがにこれは何かおかしいと思って、エラーコンソールに表示されるエラーをよく見ると、XMLのパースエラーで「属性が二重に定義されている」とメッセージが出ている。それでピンと来てTab Mix Plusのソースを見てみたら、怪しい記述を見つけた。オーバーレイ用のXULドキュメントで、idがmain-windowであるwindow要素のオーバーレイ内容にXML名前空間宣言が含まれている、というものだ。もちろんこれはXML的に全く問題がないはずの記述なのだけれども、まさかと思いながらそこを書き換えてみたら、Tab Mix PlusがあってもcreateContextualFragment()が失敗しなくなった。それで、ここが原因だと確信が持てたということで、Bugzillaにバグとして報告してみた。

Bug 510157 – nsIDOMNSRange.createContextualFragment() fails when there is applied XUL-overlay including XML namespace declarations

条件がややこしい上に、一体どこが一番悪いのか分からなかったんだけど、一番表面上のトリガーになってるように見えてるのがDOM Traversal-Rangeだったので、そこのバグとして報告してある。

この問題を回避しようと思ったら、Tab Mix PlusのオーバーレイでXML名前空間宣言を書くのは本当のルート要素だけという風に書き換えるのが一番手っ取り早いんだけど……できれば本体(Gecko)の方を直してほしい所ではある。

removeEventListenerに起因するコンフリクト - Sep 27, 2005

割と最近までMozillaには、あるイベントリスナを無効にするのにremoveEventListener()メソッドを使うと、他のイベントリスナまでも巻き添えに無効にしてしまうというバグがあった。拡張機能同士のコンフリクトの中でも最も厄介なトラブルは、これに起因するものだ。

ウィンドウの読み込み完了時のタイミングで初期化処理を行うために、addEventListener()で初期化関数をloadイベントのリスナとして登録することがよくある。イベントハンドラは一つしか登録できないのに対して、イベントリスナならいくつでも登録可能だからだ。

で、メモリの解放し忘れを防ぐために気を利かせて、この初期化専用のイベントリスナをremoveEventListener()で登録解除するようにしていると、冒頭の問題にぶち当たってしまう。ある拡張機能の初期化処理が行われたら、その次にイベントリスナとして登録されている初期化処理が行われなくなってしまう、ということが起こるのだ。Popup ALT Attributesの25日版とTab Mixとのコンフリクトは、たまたまこの二つがその順番でインストールされていたからこのような形で問題が表面化したに過ぎず、本質的には、Popup ALT AttributesにもTab Mixにも非は無い。あくまでMozillaのバグだ

こんなのまで僕の落ち度にされちゃあたまったもんじゃないですよ、なんで僕がMozillaのバグの尻拭いで説明と対応をさせられなきゃあならないんですか、ってんですよ……ブツブツ……

TBEでリンクをクリックしたときの挙動を制御できなくなっている問題の解決の糸口 - Sep 25, 2005

テストケースを見る限り、HTMLの属性としてイベントハンドラを定義しているケースについては対処可能のようだが、JavaScriptでイベントハンドラを追加している場合については対処不可能だ。

やっぱリ手詰まり。

――マニフェストファイルをいじって、セキュリティの制限を緩くするようにした。僕が把握してる範囲では、攻撃可能な穴はなさげだけれども、穴ってのは大抵、予想もしてないところから見つかるからなあ……まあその時にはその時だ。

Google ToolbarとPopup ALT Attributesのコンフリクト - Sep 25, 2005

冗談じゃないっすよ。これを以て「Piroの作る物はやっぱ穴だらけだな」とか言われるだなんて。実装見たら明らかじゃないすか。今回の問題はどー見たってGoogle Toolbarの横暴が原因ですよ。

Google Toolbarの野郎、こともあろうにイベントハンドラそのものを上書きしくさりやがってる。こちとら可能な限り元のコードに影響を与えない方法を考えてあれこれ対策してるってえのに、そんな配慮のカケラもない。そんなの知ったこっちゃないね、俺様は天下のGoogle様なんだからFirefoxのコードを引っかき回したって許されるんだぜ、そんな驕りが窺い知れるってもんですよ。

ああムカツク。

――と、よく調べずにキレてたんだけど、どうも違う原因っぽい?

――ちゃんと調べてみたら、やっぱりGoogle Toolbarが悪者だということがはっきり分かった。

続きを表示する ...

TBEでタブグループの親になっているタブを閉じられないことがある問題 - Sep 25, 2005

調べていて気付いたけど、これは、子タブについての扱いが、コードを書いた時期によって変わってしまっていることが原因だった。ある時期には「タブの要素ノードの配列」、またある時期には「タブのID文字列の配列」、またあるときは「タブのID文字列の配列をパイプ("|")で連結したもの」と、もー、バラバラ。

JavaScriptは型チェックのない言語なので、こういうことがよく起こる。コーディング時に意識を高く保つ必要があるのが、JavaScriptの欠点といえば欠点ですな。

TBEでリンクをクリックしたときの挙動を制御できなくなっている問題 - Sep 24, 2005

タブのロックやなんかの機能が全然働かなくなっていたことに今頃気付いて原因を調べていた。どうも、これも案の定Split Windowの影響らしい。

TBEでは、要素ノードにonclickとかoncommandとかのイベントハンドラがあった場合にはそれを一旦フックして、イベントハンドラの返り値を取得し、falseが帰ってきたときにはリンクを読み込む処理をキャンセルする、ということをやってるんだけど……どうもSplit Windowの変更が入ってからこっち、onclickその他のプロパティにアクセスしようとしただけでNS_ERROR_NOT_AVAILABLEのエラーが発生するようになってしまったようだ。これは痛い。返り値を取得できなくなってしまったことも痛いんだけど。

かといって、 xpcnativewrappers=noにしつつ完璧なセキュリティ対策を施せるだけの自信もないんだよなあ。

どうしたものか……

ていうか、もう、TBE捨ててイイっすか? 投げ出したくてたまらんのだけど。更新すればするほど糞糞言われるしさ(自分でも言ってるけど)。なんでこんな拷問みたいな事続けてるんだろ……

TBEでタブを並べ替えるとおかしくなる問題4 - Sep 16, 2005

普通にドラドロするだけでもタブのドロップ位置がズレたりしてたのでついでに直した。今の今まで放置してた辺り、いかに自分が普段この機能を使っていないかが窺い知れるというものですね。

TBEでタブを並べ替えるとおかしくなる問題3 - Sep 16, 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]までにしかアクセスできないはず)。これ、JavaScript 1.6の仕様変更に伴う挙動の変化ですか?

とにかくこのせいで、nodelist[index]にアクセスしてundefinedが返ってくるかどうかで添え字がインデックスの範囲を超えてるか超えてないかを判別していた部分が誤判定を起こすようになってしまっていた。

こんなの、他にどれだけあるか分からんよ……よう探しきれませんorz

TBEでタブを並べ替えるとおかしくなる問題2 - Sep 15, 2005

全然違う原因だったぽ(´・ω・`)

並べ替え処理の前後でプロパティがどう変化しているのか……を調べようと思ってalert()でちまちまやってたら、なんか突然問題が起こらなくなっちゃったんすよね。なんで? ただプロパティの値を見ただけなのに?

よくよく調べてみると、どうやら、getterになっているとあるプロパティに一度もアクセスしないままにタブを閉じると、そのgetterから正しい値を取得できなくて、エラーになっていたということのようだ

こんなのわかんねーよ!!

ということで、タブを並べ替えた直後に一度だけgetterを参照してプロパティで正しい値を取得できるようにしたところ、問題の現象は起こらなくなった。

こんなことで僕はまた何日もムダにしたのか……orz

TBEでタブを並べ替えるとおかしくなる問題 - Sep 15, 2005

原因なんとなく分かった。「最初のタブ」が全ての元凶。

僕は普段、全てのタブを閉じた場合にはタブバーを表示しない設定にしていて、この設定では、一つめのタブを開いたり何らかのページを読み込むと、自動的に新規タブを開いて、入れ替わりに最初のタブを閉じるという動作になる。つまり、最初のタブはすぐに消える。だから問題が表面化しなかった。最初のタブを消さずにそのまま使い続けると、中途半端な初期化処理のせいで、色々と問題が起こる。

一番簡単な解決策は、起動時に「最初のタブ」を自動的に閉じてしまうこと(そしてその代わりに新しいタブを開くこと)なんだけど……

Page 1/248: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき