Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
Firefox 3.1で入りそう・もう入ること確定の変更点 - Oct 27, 2008
- Firefox3.1 Tab strip should be a toolbar instead - alice0775のファイル置き場 - Yahoo!ジオシティーズ→問題のパッチ（まだチェックインされてないので最新のパッチはバグの方でチェック）
- Firefox3.1b2pre nsContextMenu が模様替え - alice0775のファイル置き場 - Yahoo!ジオシティーズ→問題のパッチ
前者は3.1ブロッキングにもなってないし確定というわけではないようだけど、影響範囲があまりにでかくて入れば僕の作ってる奴も全滅は間違いないので注視しておきたい。
後者はもう入ってるので、見落としが無いようにパッチの隅々までチェックしておかないと。
ていうかほんとMozillaの世界の「ベータ」ってアテにならない表現だよね……ファイナルベータでアルファ版級の変更をぶち込んできたりとかさ。
UxUこっそり改良進行中 - Oct 26, 2008
UnitTest.XULとかUxUとかうずとかいうアレ。サイトの方は長らく放置してますが、地味に作業してます。
- テスト専用のプロファイルを指定してテストを実行する機能。Ruby on Railsのfixtureみたいな。
- ユーザプロファイル内でなくアプリケーションのインストール先の方に自動インストールする機能。
- テストの実行結果をファイルに保存する機能。
- Thunderbirdでメール送信のテストをしたい、という時のために、メールを送信する処理を実行したら、実際にはメールを送信しないでローカルのどこかに溜め込んで、その内容を普通に文字列として取れる仕組み。Ruby on Railsのメール関係のテストの仕組みのような。
プロファイルを指定してテストを実行する、というのはずっと前からやりたいと思ってた。これができると機能テストとか結合テストとかいう段階のテストが圧倒的に楽になる……はず。
ルーラーバー 0.3.2008102201 - Oct 22, 2008
Ruler Bar更新した。結局、今までのやり方はほとんど全部うっちゃって、ピクセル単位で位置合わせするようにした。
ピクセル単位で現在のカーソル位置を取得するには、カーソル位置＝長さ0の選択範囲の位置に何かダミーの要素を挿入して、その要素の画面上でのX座標を取得すればいい。ただ、メール本文の編集中にこれをやると、場合によっては再描画とかノードがブツ切りにされまくるとかでかなり怖いことになるんじゃないだろうかという心配があったり、そもそもテキストノードの切断を伴うような処理をやると選択範囲が失われる（＝カーソルが一時的に消える）のでその復活のための処理が面倒だったり、といくつかの理由があってこの方法を採るのをずっとためらってた。
でも上手い解決方法を思いついたので、今回この方法に切り替えることにした。
種を明かすと、非表示のフレームを一つ用意しておいて、編集中のメール本文のうちカーソルがある段落の箇所だけをその隠しフレームに複製して、そっちでテキストノードの切断を伴うような処理をやってる。フォントや文字の大きさ、body要素の幅などを合わせてやれば、そこで起こる折り返しは基本的に本物と全く同じ結果になるはずなので。編集されるのは複製の方で、しかもカーソル前後の段落だけ抜き出したものだから、ノードを切り刻んでも再描画のコストは最低限で済んでる……と思う。
分割ブラウザ、マルチプルタブハンドラの連携の改善 - Oct 19, 2008
Firefox 3.1からの変更への対応に関する技術情報の中に書いたけど、分割ブラウザとマルチプルタブハンドラの連携を強化したり、分割ブラウザ側の「分割された領域」と「タブ」の連携を大幅に強化したりした。
ということをグダグダグダグダ書いてみても大して伝わらんだろうなあと思うので、実際に動いてる所のデモ動画を作ってみた。
<object width="425" height="350"> <param name="movie" value="http://www.youtube.com/v/-rfZNBy0jic"></param> <embed src="http://www.youtube.com/v/-rfZNBy0jic" type="application/x-shockwave-flash" width="425" height="350"></embed> </object>
Firefox 3.1上でなら擬似的な移動でなくホントの移動になるから、ストレスが無いし、書きかけのテキスト等が失われる心配も無いので、今以上にはるかに気軽に使えると思う。作った自分自身、これらの点がネックで今はほとんど使ってないので……
デモ動画自体の作り方もメモしておく。キャプチャはCamStudio、セッティングは「描いてみた」動画の作り方を参考に、ただしフレームレートは高めで。編集はNicoVisualEffectsでやった。CamStudio＋ffdshowでH264でエンコードしたaviが読み込めなくて詰まったけど、Wikiに挙がってたDirectShowプラグインというのをを入れたらちゃんと読み込めた。そんな具合で、初めてなんでちょっと手こずったけど、DebugMode Winkを使って作るのに比べるとタイムライン操作がやりやすいので、今後はデモ動画を作る時はこのやり方でいこうと思う。
ウィンドウ間でのタブの移動、というか、フレームの内容の入れ換え - Oct 19, 2008
Firefox 3.1からは、ウィンドウをまたいでタブを移動できるようになる。アドオンの作者はこれに合わせて修正を行わないといけない場合がある。
また、この機能を実現するために新しく用意された「表示されている2つのフレームの内容を破壊せずに入れ換える」APIは、他の目的でも利用することができる。
タブ系拡張機能 - Oct 16, 2008
そんなわけで（？）、TBE3に含まれる4つともアップデートした。
情報化タブの機能として、Firefox 3.1向けに、最後のタブのクローズボックスを強制的に表示させるオプションを加えた。本体の方でまた隠し設定がどうとか色々変わりそうな気もするけど、とりあえず現時点での仕様に合わせておく。不要になったら機能自体削除の可能性もある。
ソース表示タブは、機能は変わってないんだけど、動的に書き換えてるメソッド類がMinefieldでだいぶ変わってるようだったので、その修正が主。
マルチプルタブハンドラは、ツリー型タブの修正で書いたのと同じ要領でMenu Editorとの競合を解消したり、ツリー型タブと組み合わせた時の地味なトラブルを直したり、といった程度。
ツリー型タブ - Oct 15, 2008
ツリー型タブ 0.7.2008101501。前の版から4ヶ月も経ってた。使ってて見つけたバグはちまちま直してたんだけど他のユーザの人から英語で寄せられるバグ報告を放置放置でほったらかしてる間にまたずいぶん溜まってしまったのでちょっと頑張って処理してみた。FireGesturesの仕様変更への追従なんてもう何ヶ月も前の変更だから、もう意味が無くなってるかもしれないけど……まあ誰かに言われたら直そう（ぉぃ）。
Menu Editでタブのコンテキストメニューの項目が無限増殖する問題は、多分、分割ブラウザとの組み合わせを見越して各tabbrowser要素ごとにポップアップメニューの項目に一意なid文字列を生成するようにしていたせいだと思う。<tabbrowser id="content"/>なやつだけ特別に固定のidにするようにして、手元で試した限りでは無限増殖の問題は起こってない。マルチプルタブハンドラでも同じ問題が起こってるはずなので（報告すでに受けてたかも。あまりに多すぎて埋もれてしまってる可能性大。）、これは次のリリースで同じ修正を入れます。
Tab Mix Plusとの組み合わせで色々問題が起こってるという報告を受けてるけど、設定項目が多すぎてどの組み合わせで問題が起こるのか分からないのでお手上げです。とりあえず簡単に手元で試して再現しなかった物は放置。
ルーラーバーで折り返された行のカーソル位置を正しく表示できるようになったよ - Oct 11, 2008
ルーラバーだとやっぱり行ったことのある場所に行くあの呪文しか思い浮かばないという声があったので、日本語名をルーラーバーに変えた。
そのルーラーバーなんだけど、Rulerrrrrでもあった「折り返された次の行の先頭にカーソルがある時や行末にカーソルがある時にルーラー上の現在位置表示がおかしくなる（カーソル位置の計算に失敗する）問題」に真面目に取り組んで、0.2.2008101101でだいぶ改善した。
背景
ルーラーバーもRulerrrrrも、現在のカーソルの位置を計算するのには選択範囲を使っている。FirefoxやThunderbirdではカーソル位置をJavaScriptから直接取得することはできないんだけど、現在カーソルがある位置は長さ0の選択範囲として取得できるので、選択範囲が含まれているノードとか選択範囲の開始・終了位置などからどうにかこうにかして「カーソルより前に何文字あるか」を数えて、カーソル位置を割り出している。
行末にカーソルがある時
行末にカーソルがある時にカーソル位置が0（行頭）と判定されてしまっていたのは、この選択範囲から選択範囲が含まれているノードを取得できないせい。どういう事かというと、行末にカーソルがある状態というのは「テキストノード」「改行のBR要素」「テキストノード」という順番にノードが並んでいてBR要素の直前に長さ0のRangeがあるという状態で、「選択範囲が含まれているノード」は前後の要素やテキストノードではなくいきなりBODY要素になってしまう、ということでカーソル位置の求めようがなくなっていた。
そこで、TreeWalkerを使って各行のテキストノードやBR要素を走査し、compareBoundaryPoints()でそのノードがカーソルに隣接しているかどうかを調べる、という風な処理を入れてみた。これにより、行末にカーソルがある時でもカーソルより前にある文字を数えられるようになった。
折り返された行の行頭・行末判別
折り返された行の処理はもうちょっと厄介だった。普通に考えたら、「カーソル位置より前の文字数÷折り返し文字数 の余り」でカーソルの現在位置が分かるはずなんだけど、実際にはこれだけじゃダメだった。FirefoxやThunderbirdのエディタ機能では、折り返された行の行末にカーソルがある時に右キーを押すと、次の文字（折り返された次の行の先頭文字）の後の位置にカーソルが移動するのではなく、次の文字の前・仮想的な改行文字の後にカーソルが移動してしまう。折り返された後の行頭で左キーを押した時も同様。なので、いくら文字数ベースで計算しても、今「折り返された行の折り返し直前にカーソルがある」のか「折り返された後の行の先頭にカーソルがある」のかは分からない。
幸い、選択範囲の変更（＝カーソルの移動）を監視する時にはその選択範囲の変更が発生したユーザの操作の種類がある程度分かる。なので、マウス操作でのカーソル移動については、行の左の方でのクリックでカーソルが移動した時は行頭、そうでなければ行末と判定するようにした。また、キー操作でのカーソル移動については、「直前にいた位置が行頭・行の中程・行末のどれだったか」と「どのキーが押されたか」の組み合わせを元に、今カーソルがどの位置にあるかを推測するようにした。
英単語等があるせいで予定の文字数より前で折り返しが発生した時や、HTMLでプロポーショナルフォントが使用されている時、画像がある時などについてはもう完全にお手上げです。カーソルの位置をピクセル単位で取れるようなAPIが付いてくれないことには、もうどうにもなりません。
旧ドラッグ＆ドロップAPIから新ドラッグ＆ドロップAPIへの移行 - Oct 02, 2008
Fx3.1b1pre tabbrowser全滅で報じられているとおり、Bug 456048 – Use the new D&D API in tabbrowserによって、tabbrowser要素のドラッグ＆ドロップ関係の処理がHTML5で定められた仕様に基づいたものに変更されたようだ。
新APIの使い方についてはGomitaさんが分かりやすい解説を連載で書いてくださっているので、そちらを見てもらうとして。
パッチを見た感じでは、可能な限り最小の変更で新APIに移行していたので、ツリー型タブにも手を入れてみた。変更点を見ると分かるけど、以下のようにしている。
- メソッド名の変更に追従した。
onDragStart→_onDragStart（ツリー型タブでは触ってないけど）onDragOver→_onDragOveronDragExit→_onDragLeavecanDrop→_setEffectAllowedForDataTransfer
- 各メソッドの引数から
aDragSessionが消えたので、Cc['@mozilla.org/widget/dragservice;1'].getService(Ci.nsIDragService).getCurrentSession();でその都度取得するようにした。 canDropの代わりの_setEffectAllowedForDataTransferは、返り値が真偽値ではなく文字列になっているので、それに合わせて色々変更。- 受け入れるデータ型の「text/unicode」が何故か「text/plain」に変わったので、他の箇所でも「text/plain」を受け入れるようにした＋他の拡張機能でドラッグを開始する時に「text/plain」もセットするようにした。
ツリー型タブでは、Firefoxのtabbrowser要素の各メソッドを書き換える時に上記の点を動的に判別して、Firefox 3.0.xとFirefox 3.1の両方に対応するようにしている。
基本的に、新APIは旧APIの機能をほとんど包含しているので、旧APIに基づいて作った拡張機能等はほとんど機能を失うことなく新APIに移行できると思う。逆に、新APIではドラッグ元要素に新しいイベントが発行されるようになっているため、それをバリバリに使った新しい機能は旧APIベースで再現するのは大変そうだ。
これに関連してMDCの最初のページだけ訳してみたけど、新しいシステムの上で訳したのは初めてだったので、だいぶ難儀した。翻訳文書新規作成支援ボットは使えないし、リンク先はいちいち手で打ち直さないといけないし、リンク先を変える時に開くプロパティみたいな画面を表示する度にいちいちものすごく待たされるし……
Firefox 2.0.0.17とThnderbird 2.0.0.17のJavaScriptエンジンに極めて深刻な問題があるようです - Sep 30, 2008
仕事で書いてるコードがどーにもうまく動かなくて、ついこないだまで正常に動いてたのにどうして？！と思って色々試していたら、特定の関数をtoString()等で文字列化した時におかしな現象が起こっていた。具体的には、Thunderbird 2.0.0.17のAccountManager.jsで定義されているsaveAccount()を書き換えようとしたら例外が発生して、onSave()を文字列にしてreplace()で改変した物はfor〜inループだった箇所がwhileループになってしまっていた。コードを削っていったらめちゃめちゃ短いコードでも再現したので、Bugzillaに報告しておいた。
上記のような方法で動的にパッチを当てる手法を僕は多用してるので、仕事で書いたコードもここで公開してる拡張機能のコードも、正直、どのくらい影響を受けるのか見当も付かない。早急に解決されることを祈るのみだ。
ちなみにFirefox 3.0.3ではこの問題は起こらなかった。2.0.0.17で入ったセキュリティ上の修正による後退バグっぽい？
追記。29日時点ですでに修正済みだったようだ。これ、あと1ヶ月間放置ですか……？ ものっそクリティカルなバグだと思うんだけど。