たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
昨日一日がかりで作ってた物をマルチプルタブハンドラという名前で公開してみた。
「TBEのFirefox 2用アップデート」というのは敷居が高すぎるというか既に情熱が枯れてしまった僕には荷が重すぎてとても不可能なので、今ある機能のうち特に自分が今よく使っている機能から順番に再実装していくことにした。こいつはその中でも、タブのクローズボックスのドラッグによる選択→まとめて閉じる という操作だけに特化した拡張機能だ。
この機能は元々はiRiderというブラウザの挙動をパクった物で、TBEの機能の中では最も最近加わったやつなんだけど、Firefox 2標準のタブの使い方を勉強するには手頃な規模の物になったと思う。
で、せっかくだから似たような実装で実現できる機能として、タブカタログの「ドラッグして選択→いろんな操作」という挙動も盛り込んでみた。メニューの内容は簡単に追加できるようにしてあるので、これからTBEの機能を分割していった後にも比較的楽にそれぞれを連携できるんじゃないだろうか……と、夢想してみている。
APIはまだちゃんとしたドキュメントは書いてないんだけど、草稿はあるんで、userChrome.jsあたりと組み合わせて誰か使ってみてくれないかなあ。とか。
あと、Tab KillerをFirefox 2向けにアップデートした時に勉強した成果を活かして、Firefox 2のセッション管理機能だけを使って「タブをウィンドウに分割」という機能も入れてみた。
何となく、この規模でこの程度の機能の物は既に誰かがもう作っちゃってるんじゃないかなーという気もするんだけど。どうなんだろ。
ていうか開発初期の数時間くらいの間、名前をどうするか悩んでて、「タブを選択したりまとめて閉じたりするアレ」とかのネタっぽい名前が結構有力候補になってたんだけど、結局こういうモヤモヤしたよくワカラン名前に落ち着いた。まあ、どうせ今頃こんなの作った所でハナから死んだプロジェクトみたいなもんだし、どうでもいいよね……
どうでもいいといえばこれはほんとにどうでもいいんだけど、「マルチプルタブハンドラ」てカタカナで書くと「ハムナプトラ」とか「アルハンブラ」とかそういうのと混乱して困る。
複数ページに分かれている続き物のコンテンツを動的に結合して表示するGreasemonkeyスクリプトのPage Concater(バージョン0.10.0)を使っていると日経ビジネスオンラインの記事でうまく動作しないどころか次のページにすら進めなくなってしまった。
concater.REG_BODY = '<div class="articlecontent">(.*?)<!-- /articlecontent -->';
ここを
concater.REG_BODY = '="articlecontent">(.*?)(<!-- /articlecontent -->|<div align="center">)';
と書き換えてみたら、ちゃんと動くようになった。あと、そもそも前後のページがあるということ自体認識できない場合もあったけど、これについては、
el.href.match(/P=(\w+$)/);
ここを
el.href.match(/P=(\w+)(&.+)?$/);
に直したら改善された。
Split BrowserとGoogle Notebook Extensionがコンフリクトしてるという報告を受けて調べてみた結果のメモ。
XULでは、というかGeckoでは、iframeもbrowserも、インラインフレームについてはCSSのz-indexプロパティの指定とは関係なく、一番最後に描画されたものが一番上に表示されるようになっている。たぶんバグなんだけど、長年そのままになってるから、仕様ということになってるのかもしれない。
Google Notebook Extensionはウィンドウ内にインラインフレームを生成して絶対配置でメインのブラウザ領域の上に重ねて表示してるんだけど、Split Browserで新しいブラウザ領域を追加すると、それがGoogle Notebook Extensionのフレームよりも上に描画されてしまう、というのが問題の現象だ。この問題は分割後の領域でタブを切り替えた際にも発生する。
Google Notebook Extensionのデフォルトの挙動を調べてみると、メインのブラウザ領域については、タブを切り替える度にGoogle Notebook Extensionのフレームを表示し直すようになっていることが分かった。つまりこれと同様に、Split Browserでブラウズ領域を分割した時と、それらの領域内でタブを切り替えたときにも、Google Notebook Extensionのフレームを表示し直してやればいいということになる。
ただ、検証中にさらにもう一つ問題が発覚した。deck要素で内容を切り替えた部分と重なるGoogle Notebook Extensionの領域が白く抜けて描画されてしまうというものだ。deckを使わないようにすればどうにかなりそうなんだけど、そうするとツールバーの高さがガタついてしまうので、どうしたらよいか悩んでいる。
無効にするべき10の拡張機能。リンクされてたので見てみた。
要約すると、以下の10の拡張機能はこういう風にダメだから窓から投げ捨てろと書いてある。
大別すると「迷惑だから使うな」系と「大して役に立たないよ(メリットとデメリットが釣り合わないよ)」系に分類できるか。
後者のグループについては、大きなお世話という気がする。本人が感じるメリットとデメリットを天秤にかけて選んでるんだから、他人の感覚でどうこう言う筋合いではない。まあ、有効に活用してない人を見ると確かに「あーあ」って気はするけど。All-in-One Gesturesをわざわざ導入してるのに「戻る」と「進む」くらいにしかジェスチャ使ってない、とかね。
m.tamaki氏によるエントリとFirefox Hacksを見ながら自分でも試してみた。オブジェクト署名証明書が無いので、とりあえずオレオレ証明書での実験だけど。
Tab Catalogの一覧表示を開く時にもたつく問題の改善方法を、実験を交えながら改めて検討してみた。
色々試してみて分かったのは、どうもHTML CanvasをDOMツリーに埋め込んだ後、描画されるまでの間がもたついているらしいということ。何も描画していなくても、Canvas要素を埋め込むだけでだいぶ時間がかかるっぽい。
ということでサムネイル用のプレースホルダーだけ用意しておいてCanvas要素をタイマーで一つずつ追加するようにしてみたところ、ホットキーを入力した直後の反応が格段に良くなった。トータルではあまり変わってないか、むしろ遅くなってる可能性もあるけど、体感的にはこっちのほうがずっといい。
Leak Monitorっててっきりもっとディープな人向けの物だと思ってたんだけど、入れてみたら、ふつうにJavaScriptのコードの中で起こってるメモリーリークを指摘してくれるツールだった……いろいろなプラットフォームで動くようなので、拡張機能の開発やるなら入れておいて損は無いと思う。
Firefoxのウィンドウを閉じたときに、本来は開放されていなければいけないのに開放されていないオブジェクトがあった場合、そのオブジェクトと、オブジェクトが定義されているコードのURIを表示してくれる。よくあるのはイベントリスナとかプログレスリスナとかオブザーバとかの登録解除のし忘れ。あとXBLのdestructorが動いてくれてないこともあったりするから手動で破棄するべきポイントのあぶり出しにも使える。と思う。Split Browserと2 Pane Bookmarksでずっと気付いてなかったメモリーリークをつぶすことができたのは、これのおかげだ。
ただ、「このオブジェクトが開放されてないよ」ということは教えてくれるんだけど、その原因までは教えてくれない(そこは自分でコードを精査して分析しないといけない)のが、微妙に残念だった。まあそれが当り前なのかも知れんけどさあ。
それはそうと、なんかうちの環境だとこのページ見るだけでメモリーリークが発生してるんですが。
Firefoxの主要機能を開発するために投じられた多くの人々の多大な努力をぶち壊しにする悪夢の拡張機能、タブキラーがFirefox 2のために帰ってきましたよ。
Firefox 2正式対応は伊達じゃない。今回のアップデートではなななななんと! Firefox 2の新機能の「最近閉じたタブをもう一度開き直す」機能をいじくり倒して、「最近閉じたウィンドウをもう一度開き直す」という機能に作り替えてみました。ああ激しく無駄な努力。
ソース見ればだいたい分かると思うけど、一応、実装の仕方を以下に説明しておく。
URNサポートをさらに更新して、今度こそあらゆる場面でちゃんとURNをURLにリダイレクトできるようにした。
何かヒントはないかと思ってbbs2chreaderのb2rThreadRedirector.jsを見たら、nsIContentPolicyの実装?を使って内部的にリダイレクトを行えるようだということが分かった。リダイレクト処理をプロトコルハンドラから分離して同様の実装に移してみたところ、うまくいった。URN用のプロトコルハンドラは現在では、単にurn:というスキーマのURIへのアクセスを受け付けるための役割しか果たしていない。
というわけで、以下、Firefox内部でリダイレクトを行う方法をメモしておこう。
なんで独自プロトコルへの対応方法なんか訳してたのかというと、URNサポートを抜本的に改善したかったからなのですよ、と。
今までは、URIの読み込みを行う関数やメソッドについて、URNが渡されたらURLに置き換えてから本来の処理に渡すようにあちこち書き換えるという、とてつもなく泥臭いことをしていたので、場面によってはURNをリダイレクトできないこともあった。今回の更新ではこのやり方を全面的に改めて、プロトコルハンドラを使って「urn:」というスキーマへ対応するという形に構造を作り替えたので、基本的にはどんな場面からでもURNを対応するURLにリダイレクトできるようになった。
チャンネルの生成時にそのままリダイレクト先のURLを渡すとロケーションバーにURNが表示されてるのにAmazonのページが表示される、みたいな問題を回避するのにだいぶ手こずった。結論から言うと、data: URLでHTML文書片を渡したところなんとかうまくいくようになった。と思う。
……あ。逆に、browser以外で読み込んだらこれじゃマズいことになるか……