たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
分離したサイドバーのウィンドウ内でidがreporterItemsBroadcasterなbroadcaster要素が破棄されると、タブを切り替えてもタイトルバーの内容が変わらないという問題が起こる、ということが判明した。ここが原因のようだ。
調べてみたら、これはFirefox 1.5で正しく表示できないサイトを報告するための「Reporter」が使用している要素らしい。処理が記述されている reporterOverlay.jsの中を見たら、一発だった。
Reporterはウィンドウを開いた時にプログレスリスナをgBrowserに対して設定する。このプログレスリスナはページ読み込みのタイミングで「ブラウザに読み込まれたURI」を調べ、Reporterでレポート可能な種類のページかどうかを判別し、先のbroadcasterにdisabled属性として指定する。これによってReporterのメニュー項目が必要に応じて有効化・無効化されるという寸法だ。
問題は、ウィンドウを閉じるときにこのリスナが登録解除されないところにあった。サイドバーのウィンドウが閉じて、broadcasterが消滅しても、このリスナは生存し続ける。ページが読み込まれると、存在しないbroadcasterを参照しようとしてエラーになる。その結果、他のプログレスリスナの処理までもがこいつのせいで中断されてしまって、ウィンドウのタイトルバーの内容が更新されないという問題につながる。
自分で確認したのは以下の現象。
Ez Sidebarでは分離したサイドバーを正常に動かすために、他の拡張機能や組み込まれたパネル自身に対して「このウィンドウはFirefoxのブラウザウィンドウですよ」と見せかけるよう、いくつかのプロパティや関数を再定義している。プロパティはObject.__defineGetter__()
を使って再定義していて、参照するとFirefoxのブラウザウィンドウの同名プロパティを返すようになっている。つまりこのgetterを通じて、サイドバーのウィンドウとブラウザウィンドウとは繋がっている。
よって、サイドバーのウィンドウ内でこのプロパティに何か変更を加えれば、それはブラウザウィンドウ内で変更がなされたのと同じことになる。バインディングのdestructorやunloadイベントでの終了処理でそういった処理を行っていれば、サイドバーのウィンドウを閉じたタイミングで、ブラウザウィンドウの終了処理が一部分だけ実行されてしまうことになり、結果、ブラウザウィンドウの挙動がおかしくなる。こういう事ではないかと考えられる。具体的にどこら辺の処理がそうなのかは、まだ分からないんだけど。
根が深いなあ。
自分で確認したのは以下の現象。
Ez Sidebarでは分離したサイドバーを正常に動かすために、他の拡張機能や組み込まれたパネル自身に対して「このウィンドウはFirefoxのブラウザウィンドウですよ」と見せかけるよう、いくつかのプロパティや関数を再定義している。プロパティはObject.__defineGetter__()
を使って再定義していて、参照するとFirefoxのブラウザウィンドウの同名プロパティを返すようになっている。つまりこのgetterを通じて、サイドバーのウィンドウとブラウザウィンドウとは繋がっている。
よって、サイドバーのウィンドウ内でこのプロパティに何か変更を加えれば、それはブラウザウィンドウ内で変更がなされたのと同じことになる。バインディングのdestructorやunloadイベントでの終了処理でそういった処理を行っていれば、サイドバーのウィンドウを閉じたタイミングで、ブラウザウィンドウの終了処理が一部分だけ実行されてしまうことになり、結果、ブラウザウィンドウの挙動がおかしくなる。こういう事ではないかと考えられる。具体的にどこら辺の処理がそうなのかは、まだ分からないんだけど。
根が深いなあ。
自分で確認したのは以下の現象。
Ez Sidebarでは分離したサイドバーを正常に動かすために、他の拡張機能や組み込まれたパネル自身に対して「このウィンドウはFirefoxのブラウザウィンドウですよ」と見せかけるよう、いくつかのプロパティや関数を再定義している。プロパティはObject.__defineGetter__()
を使って再定義していて、参照するとFirefoxのブラウザウィンドウの同名プロパティを返すようになっている。つまりこのgetterを通じて、サイドバーのウィンドウとブラウザウィンドウとは繋がっている。
よって、サイドバーのウィンドウ内でこのプロパティに何か変更を加えれば、それはブラウザウィンドウ内で変更がなされたのと同じことになる。バインディングのdestructorやunloadイベントでの終了処理でそういった処理を行っていれば、サイドバーのウィンドウを閉じたタイミングで、ブラウザウィンドウの終了処理が一部分だけ実行されてしまうことになり、結果、ブラウザウィンドウの挙動がおかしくなる。こういう事ではないかと考えられる。具体的にどこら辺の処理がそうなのかは、まだ分からないんだけど。
根が深いなあ。
自分で確認したのは以下の現象。
Ez Sidebarでは分離したサイドバーを正常に動かすために、他の拡張機能や組み込まれたパネル自身に対して「このウィンドウはFirefoxのブラウザウィンドウですよ」と見せかけるよう、いくつかのプロパティや関数を再定義している。プロパティはObject.__defineGetter__()
を使って再定義していて、参照するとFirefoxのブラウザウィンドウの同名プロパティを返すようになっている。つまりこのgetterを通じて、サイドバーのウィンドウとブラウザウィンドウとは繋がっている。
よって、サイドバーのウィンドウ内でこのプロパティに何か変更を加えれば、それはブラウザウィンドウ内で変更がなされたのと同じことになる。バインディングのdestructorやunloadイベントでの終了処理でそういった処理を行っていれば、サイドバーのウィンドウを閉じたタイミングで、ブラウザウィンドウの終了処理が一部分だけ実行されてしまうことになり、結果、ブラウザウィンドウの挙動がおかしくなる。こういう事ではないかと考えられる。具体的にどこら辺の処理がそうなのかは、まだ分からないんだけど。
根が深いなあ。
自分で確認したのは以下の現象。
Ez Sidebarでは分離したサイドバーを正常に動かすために、他の拡張機能や組み込まれたパネル自身に対して「このウィンドウはFirefoxのブラウザウィンドウですよ」と見せかけるよう、いくつかのプロパティや関数を再定義している。プロパティはObject.__defineGetter__()
を使って再定義していて、参照するとFirefoxのブラウザウィンドウの同名プロパティを返すようになっている。つまりこのgetterを通じて、サイドバーのウィンドウとブラウザウィンドウとは繋がっている。
よって、サイドバーのウィンドウ内でこのプロパティに何か変更を加えれば、それはブラウザウィンドウ内で変更がなされたのと同じことになる。バインディングのdestructorやunloadイベントでの終了処理でそういった処理を行っていれば、サイドバーのウィンドウを閉じたタイミングで、ブラウザウィンドウの終了処理が一部分だけ実行されてしまうことになり、結果、ブラウザウィンドウの挙動がおかしくなる。こういう事ではないかと考えられる。具体的にどこら辺の処理がそうなのかは、まだ分からないんだけど。
根が深いなあ。
自分で確認したのは以下の現象。
Ez Sidebarでは分離したサイドバーを正常に動かすために、他の拡張機能や組み込まれたパネル自身に対して「このウィンドウはFirefoxのブラウザウィンドウですよ」と見せかけるよう、いくつかのプロパティや関数を再定義している。プロパティはObject.__defineGetter__()
を使って再定義していて、参照するとFirefoxのブラウザウィンドウの同名プロパティを返すようになっている。つまりこのgetterを通じて、サイドバーのウィンドウとブラウザウィンドウとは繋がっている。
よって、サイドバーのウィンドウ内でこのプロパティに何か変更を加えれば、それはブラウザウィンドウ内で変更がなされたのと同じことになる。バインディングのdestructorやunloadイベントでの終了処理でそういった処理を行っていれば、サイドバーのウィンドウを閉じたタイミングで、ブラウザウィンドウの終了処理が一部分だけ実行されてしまうことになり、結果、ブラウザウィンドウの挙動がおかしくなる。こういう事ではないかと考えられる。具体的にどこら辺の処理がそうなのかは、まだ分からないんだけど。
根が深いなあ。
自分で確認したのは以下の現象。
Ez Sidebarでは分離したサイドバーを正常に動かすために、他の拡張機能や組み込まれたパネル自身に対して「このウィンドウはFirefoxのブラウザウィンドウですよ」と見せかけるよう、いくつかのプロパティや関数を再定義している。プロパティはObject.__defineGetter__()
を使って再定義していて、参照するとFirefoxのブラウザウィンドウの同名プロパティを返すようになっている。つまりこのgetterを通じて、サイドバーのウィンドウとブラウザウィンドウとは繋がっている。
よって、サイドバーのウィンドウ内でこのプロパティに何か変更を加えれば、それはブラウザウィンドウ内で変更がなされたのと同じことになる。バインディングのdestructorやunloadイベントでの終了処理でそういった処理を行っていれば、サイドバーのウィンドウを閉じたタイミングで、ブラウザウィンドウの終了処理が一部分だけ実行されてしまうことになり、結果、ブラウザウィンドウの挙動がおかしくなる。こういう事ではないかと考えられる。具体的にどこら辺の処理がそうなのかは、まだ分からないんだけど。
根が深いなあ。
自分で確認したのは以下の現象。
Ez Sidebarでは分離したサイドバーを正常に動かすために、他の拡張機能や組み込まれたパネル自身に対して「このウィンドウはFirefoxのブラウザウィンドウですよ」と見せかけるよう、いくつかのプロパティや関数を再定義している。プロパティはObject.__defineGetter__()
を使って再定義していて、参照するとFirefoxのブラウザウィンドウの同名プロパティを返すようになっている。つまりこのgetterを通じて、サイドバーのウィンドウとブラウザウィンドウとは繋がっている。
よって、サイドバーのウィンドウ内でこのプロパティに何か変更を加えれば、それはブラウザウィンドウ内で変更がなされたのと同じことになる。バインディングのdestructorやunloadイベントでの終了処理でそういった処理を行っていれば、サイドバーのウィンドウを閉じたタイミングで、ブラウザウィンドウの終了処理が一部分だけ実行されてしまうことになり、結果、ブラウザウィンドウの挙動がおかしくなる。こういう事ではないかと考えられる。具体的にどこら辺の処理がそうなのかは、まだ分からないんだけど。
根が深いなあ。
自分で確認したのは以下の現象。
Ez Sidebarでは分離したサイドバーを正常に動かすために、他の拡張機能や組み込まれたパネル自身に対して「このウィンドウはFirefoxのブラウザウィンドウですよ」と見せかけるよう、いくつかのプロパティや関数を再定義している。プロパティはObject.__defineGetter__()
を使って再定義していて、参照するとFirefoxのブラウザウィンドウの同名プロパティを返すようになっている。つまりこのgetterを通じて、サイドバーのウィンドウとブラウザウィンドウとは繋がっている。
よって、サイドバーのウィンドウ内でこのプロパティに何か変更を加えれば、それはブラウザウィンドウ内で変更がなされたのと同じことになる。バインディングのdestructorやunloadイベントでの終了処理でそういった処理を行っていれば、サイドバーのウィンドウを閉じたタイミングで、ブラウザウィンドウの終了処理が一部分だけ実行されてしまうことになり、結果、ブラウザウィンドウの挙動がおかしくなる。こういう事ではないかと考えられる。具体的にどこら辺の処理がそうなのかは、まだ分からないんだけど。
根が深いなあ。