たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
なんかまた違う問題がポロポロと出てきましたよ?
タブを並べ替えたり消したりしてあれこれしてたらエラーが出るようになって、原因を探っているうちに、どうもタブの配列?がおかしくなってるらしいということに気がついた。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
全然違う原因だったぽ(´・ω・`)
並べ替え処理の前後でプロパティがどう変化しているのか……を調べようと思ってalert()
でちまちまやってたら、なんか突然問題が起こらなくなっちゃったんすよね。なんで? ただプロパティの値を見ただけなのに?
よくよく調べてみると、どうやら、getterになっているとあるプロパティに一度もアクセスしないままにタブを閉じると、そのgetterから正しい値を取得できなくて、エラーになっていたということのようだ
こんなのわかんねーよ!!
ということで、タブを並べ替えた直後に一度だけgetterを参照してプロパティで正しい値を取得できるようにしたところ、問題の現象は起こらなくなった。
こんなことで僕はまた何日もムダにしたのか……orz
原因なんとなく分かった。「最初のタブ」が全ての元凶。
僕は普段、全てのタブを閉じた場合にはタブバーを表示しない設定にしていて、この設定では、一つめのタブを開いたり何らかのページを読み込むと、自動的に新規タブを開いて、入れ替わりに最初のタブを閉じるという動作になる。つまり、最初のタブはすぐに消える。だから問題が表面化しなかった。最初のタブを消さずにそのまま使い続けると、中途半端な初期化処理のせいで、色々と問題が起こる。
一番簡単な解決策は、起動時に「最初のタブ」を自動的に閉じてしまうこと(そしてその代わりに新しいタブを開くこと)なんだけど……
TBEの「ページのソースをタブで開けるようにする機能」がうまく働かない問題について。原因は、本来新規ウィンドウとして開くはずであったchrome://global/content/viewSource.xul(viewPartialSource.xul)をタブの中に読み込んだ際に、そのウィンドウへ引数を渡す手段がなくなってしまったせいだ。
XULWindow.openDialog()は、第4引数以降の引数を開かれたウィンドウのwindow.argumentsオブジェクトに格納する。viewSource.xulやviewPartialSource.xulでは、ここからどのページのソースを開けばよいのかという情報を取得する。しかし、タブの中に読み込まれたドキュメントのウィンドウには、window.argumentsが無い。そのためこれまでは、タブの読み込みが完了した時点で、ブラウザウィンドウのコンテキストにおいて、内容ウィンドウのwindowオブジェクトにargumentsという名前のプロパティを手動で追加していた。
ところが、昨今のセキュリティの向上によって、ブラウザウィンドウのコンテキストにおいてアクセスした内容ウィンドウのwindowオブジェクトおよびそこに属しているあらゆるオブジェクトにセットしたプロパティは、内容ウィンドウのコンテキストからはアクセスできなくなってしまった。これにより、TBEは「ソースを開く」処理を行うXULドキュメントに対して「どこのソースを開けばよいのか」という情報を受け渡す手段を失ってしまった。
今、何かうまい対策はないものかと思案しているけれども、これはもうどうにもならないような気がする。特に、選択範囲の情報を受け渡さなくてはならないviewPartialSource.xul, viewPartialSource.jsは、本気でなんとかしようと思ったら、自力で全ての挙動を再現しなくてはならないような勢いだ。
ということで4時間くらい行き詰まってウンザリしたので考えるのをやめた。鬱。誰か助けて。
ていうかもうあまりの報われなさにやる気なくした。
TBEの「ページのソースをタブで開けるようにする機能」がうまく働かない問題について。原因は、本来新規ウィンドウとして開くはずであったchrome://global/content/viewSource.xul(viewPartialSource.xul)をタブの中に読み込んだ際に、そのウィンドウへ引数を渡す手段がなくなってしまったせいだ。
XULWindow.openDialog()は、第4引数以降の引数を開かれたウィンドウのwindow.argumentsオブジェクトに格納する。viewSource.xulやviewPartialSource.xulでは、ここからどのページのソースを開けばよいのかという情報を取得する。しかし、タブの中に読み込まれたドキュメントのウィンドウには、window.argumentsが無い。そのためこれまでは、タブの読み込みが完了した時点で、ブラウザウィンドウのコンテキストにおいて、内容ウィンドウのwindowオブジェクトにargumentsという名前のプロパティを手動で追加していた。
ところが、昨今のセキュリティの向上によって、ブラウザウィンドウのコンテキストにおいてアクセスした内容ウィンドウのwindowオブジェクトおよびそこに属しているあらゆるオブジェクトにセットしたプロパティは、内容ウィンドウのコンテキストからはアクセスできなくなってしまった。これにより、TBEは「ソースを開く」処理を行うXULドキュメントに対して「どこのソースを開けばよいのか」という情報を受け渡す手段を失ってしまった。
今、何かうまい対策はないものかと思案しているけれども、これはもうどうにもならないような気がする。特に、選択範囲の情報を受け渡さなくてはならないviewPartialSource.xul, viewPartialSource.jsは、本気でなんとかしようと思ったら、自力で全ての挙動を再現しなくてはならないような勢いだ。
ということで4時間くらい行き詰まってウンザリしたので考えるのをやめた。鬱。誰か助けて。
ていうかもうあまりの報われなさにやる気なくした。
TBEの「ページのソースをタブで開けるようにする機能」がうまく働かない問題について。原因は、本来新規ウィンドウとして開くはずであったchrome://global/content/viewSource.xul(viewPartialSource.xul)をタブの中に読み込んだ際に、そのウィンドウへ引数を渡す手段がなくなってしまったせいだ。
XULWindow.openDialog()は、第4引数以降の引数を開かれたウィンドウのwindow.argumentsオブジェクトに格納する。viewSource.xulやviewPartialSource.xulでは、ここからどのページのソースを開けばよいのかという情報を取得する。しかし、タブの中に読み込まれたドキュメントのウィンドウには、window.argumentsが無い。そのためこれまでは、タブの読み込みが完了した時点で、ブラウザウィンドウのコンテキストにおいて、内容ウィンドウのwindowオブジェクトにargumentsという名前のプロパティを手動で追加していた。
ところが、昨今のセキュリティの向上によって、ブラウザウィンドウのコンテキストにおいてアクセスした内容ウィンドウのwindowオブジェクトおよびそこに属しているあらゆるオブジェクトにセットしたプロパティは、内容ウィンドウのコンテキストからはアクセスできなくなってしまった。これにより、TBEは「ソースを開く」処理を行うXULドキュメントに対して「どこのソースを開けばよいのか」という情報を受け渡す手段を失ってしまった。
今、何かうまい対策はないものかと思案しているけれども、これはもうどうにもならないような気がする。特に、選択範囲の情報を受け渡さなくてはならないviewPartialSource.xul, viewPartialSource.jsは、本気でなんとかしようと思ったら、自力で全ての挙動を再現しなくてはならないような勢いだ。
ということで4時間くらい行き詰まってウンザリしたので考えるのをやめた。鬱。誰か助けて。
ていうかもうあまりの報われなさにやる気なくした。
TBEの「ページのソースをタブで開けるようにする機能」がうまく働かない問題について。原因は、本来新規ウィンドウとして開くはずであったchrome://global/content/viewSource.xul(viewPartialSource.xul)をタブの中に読み込んだ際に、そのウィンドウへ引数を渡す手段がなくなってしまったせいだ。
XULWindow.openDialog()は、第4引数以降の引数を開かれたウィンドウのwindow.argumentsオブジェクトに格納する。viewSource.xulやviewPartialSource.xulでは、ここからどのページのソースを開けばよいのかという情報を取得する。しかし、タブの中に読み込まれたドキュメントのウィンドウには、window.argumentsが無い。そのためこれまでは、タブの読み込みが完了した時点で、ブラウザウィンドウのコンテキストにおいて、内容ウィンドウのwindowオブジェクトにargumentsという名前のプロパティを手動で追加していた。
ところが、昨今のセキュリティの向上によって、ブラウザウィンドウのコンテキストにおいてアクセスした内容ウィンドウのwindowオブジェクトおよびそこに属しているあらゆるオブジェクトにセットしたプロパティは、内容ウィンドウのコンテキストからはアクセスできなくなってしまった。これにより、TBEは「ソースを開く」処理を行うXULドキュメントに対して「どこのソースを開けばよいのか」という情報を受け渡す手段を失ってしまった。
今、何かうまい対策はないものかと思案しているけれども、これはもうどうにもならないような気がする。特に、選択範囲の情報を受け渡さなくてはならないviewPartialSource.xul, viewPartialSource.jsは、本気でなんとかしようと思ったら、自力で全ての挙動を再現しなくてはならないような勢いだ。
ということで4時間くらい行き詰まってウンザリしたので考えるのをやめた。鬱。誰か助けて。
ていうかもうあまりの報われなさにやる気なくした。
TBEの「ページのソースをタブで開けるようにする機能」がうまく働かない問題について。原因は、本来新規ウィンドウとして開くはずであったchrome://global/content/viewSource.xul(viewPartialSource.xul)をタブの中に読み込んだ際に、そのウィンドウへ引数を渡す手段がなくなってしまったせいだ。
XULWindow.openDialog()は、第4引数以降の引数を開かれたウィンドウのwindow.argumentsオブジェクトに格納する。viewSource.xulやviewPartialSource.xulでは、ここからどのページのソースを開けばよいのかという情報を取得する。しかし、タブの中に読み込まれたドキュメントのウィンドウには、window.argumentsが無い。そのためこれまでは、タブの読み込みが完了した時点で、ブラウザウィンドウのコンテキストにおいて、内容ウィンドウのwindowオブジェクトにargumentsという名前のプロパティを手動で追加していた。
ところが、昨今のセキュリティの向上によって、ブラウザウィンドウのコンテキストにおいてアクセスした内容ウィンドウのwindowオブジェクトおよびそこに属しているあらゆるオブジェクトにセットしたプロパティは、内容ウィンドウのコンテキストからはアクセスできなくなってしまった。これにより、TBEは「ソースを開く」処理を行うXULドキュメントに対して「どこのソースを開けばよいのか」という情報を受け渡す手段を失ってしまった。
今、何かうまい対策はないものかと思案しているけれども、これはもうどうにもならないような気がする。特に、選択範囲の情報を受け渡さなくてはならないviewPartialSource.xul, viewPartialSource.jsは、本気でなんとかしようと思ったら、自力で全ての挙動を再現しなくてはならないような勢いだ。
ということで4時間くらい行き詰まってウンザリしたので考えるのをやめた。鬱。誰か助けて。
ていうかもうあまりの報われなさにやる気なくした。
TBEの「ページのソースをタブで開けるようにする機能」がうまく働かない問題について。原因は、本来新規ウィンドウとして開くはずであったchrome://global/content/viewSource.xul(viewPartialSource.xul)をタブの中に読み込んだ際に、そのウィンドウへ引数を渡す手段がなくなってしまったせいだ。
XULWindow.openDialog()は、第4引数以降の引数を開かれたウィンドウのwindow.argumentsオブジェクトに格納する。viewSource.xulやviewPartialSource.xulでは、ここからどのページのソースを開けばよいのかという情報を取得する。しかし、タブの中に読み込まれたドキュメントのウィンドウには、window.argumentsが無い。そのためこれまでは、タブの読み込みが完了した時点で、ブラウザウィンドウのコンテキストにおいて、内容ウィンドウのwindowオブジェクトにargumentsという名前のプロパティを手動で追加していた。
ところが、昨今のセキュリティの向上によって、ブラウザウィンドウのコンテキストにおいてアクセスした内容ウィンドウのwindowオブジェクトおよびそこに属しているあらゆるオブジェクトにセットしたプロパティは、内容ウィンドウのコンテキストからはアクセスできなくなってしまった。これにより、TBEは「ソースを開く」処理を行うXULドキュメントに対して「どこのソースを開けばよいのか」という情報を受け渡す手段を失ってしまった。
今、何かうまい対策はないものかと思案しているけれども、これはもうどうにもならないような気がする。特に、選択範囲の情報を受け渡さなくてはならないviewPartialSource.xul, viewPartialSource.jsは、本気でなんとかしようと思ったら、自力で全ての挙動を再現しなくてはならないような勢いだ。
ということで4時間くらい行き詰まってウンザリしたので考えるのをやめた。鬱。誰か助けて。
ていうかもうあまりの報われなさにやる気なくした。
TBEの「ページのソースをタブで開けるようにする機能」がうまく働かない問題について。原因は、本来新規ウィンドウとして開くはずであったchrome://global/content/viewSource.xul(viewPartialSource.xul)をタブの中に読み込んだ際に、そのウィンドウへ引数を渡す手段がなくなってしまったせいだ。
XULWindow.openDialog()は、第4引数以降の引数を開かれたウィンドウのwindow.argumentsオブジェクトに格納する。viewSource.xulやviewPartialSource.xulでは、ここからどのページのソースを開けばよいのかという情報を取得する。しかし、タブの中に読み込まれたドキュメントのウィンドウには、window.argumentsが無い。そのためこれまでは、タブの読み込みが完了した時点で、ブラウザウィンドウのコンテキストにおいて、内容ウィンドウのwindowオブジェクトにargumentsという名前のプロパティを手動で追加していた。
ところが、昨今のセキュリティの向上によって、ブラウザウィンドウのコンテキストにおいてアクセスした内容ウィンドウのwindowオブジェクトおよびそこに属しているあらゆるオブジェクトにセットしたプロパティは、内容ウィンドウのコンテキストからはアクセスできなくなってしまった。これにより、TBEは「ソースを開く」処理を行うXULドキュメントに対して「どこのソースを開けばよいのか」という情報を受け渡す手段を失ってしまった。
今、何かうまい対策はないものかと思案しているけれども、これはもうどうにもならないような気がする。特に、選択範囲の情報を受け渡さなくてはならないviewPartialSource.xul, viewPartialSource.jsは、本気でなんとかしようと思ったら、自力で全ての挙動を再現しなくてはならないような勢いだ。
ということで4時間くらい行き詰まってウンザリしたので考えるのをやめた。鬱。誰か助けて。
ていうかもうあまりの報われなさにやる気なくした。