Latest topics 近況報告

テキストリンク 3.0.2009021901とUxU 0.5.4 - Feb 19, 2009

ロケール更新ついでに。

直した問題は、「www.」で始まるドメイン名をダブルクリックした時の補完結果が「http:\/\/www.〜」になってしまうせいで読み込みに失敗するというもの。これはデフォルト設定として指定していた補完ルールのミスで、変更したのも設定ファイルだけ。デフォルト設定から変更して使ってる人は、「http:\/\」となっている所を「http://」に書き換えると、問題が直ります。

で、何故この問題を見落としてしまっていたのか、なんだけれども。

この設定が影響する処理については、既にUxU用のテストを作成してあって、自動テストを走らせた時にはこの問題は発生していなかった。テストの内容自体には問題はなくて、問題はUxUの方にあった。

テキストリンク用のテストでは、UxU 0.5.3で追加した新しいヘルパーメソッドのutils.loadPrefs()を使っていて、defaults以下にある設定ファイルを読み込んだ上でテストを行っていた。調べてみたら、これがまずかった。

この設定ファイルは元々はcontent以下に置いてあった物で、旧バージョンでは「ファイルの内容を文字列として読み込んだ後に評価して……」てな事を全部自前でやってたんだけど、Firefox 2未満のサポート打ち切りに際して、defaultsフォルダ以下にファイルを置いて読み込み処理はFirefox自身に任せるようにしたという経緯がある。

アドオンの設定ファイルはJavaScriptの関数呼び出しの形で設定が保存されている。なので旧バージョンでは、ファイルの内容を文字列として読み込んだ後、eval()でJavaScriptとして評価して設定内容を読み込んでいた。文字列の設定値として「http:\/\/」と書かれた箇所は、無意味なエスケープになるので、この時自動的に「http://」と解釈される。なので、冒頭に書いたような問題は今まで起こっていなかった。

defaults以下に置かれたファイルをFirefox自身が読み込む時も同じような感じなのだろう、と思いこんでたんだけど、よく調べてみたらそうじゃなかった。defaults以下に置かれた設定ファイルはlibprefモジュールのprefreadという、JavaScriptパーサではない独自のパーサによって解釈されていて、よくよく見てみると、\"、\'、\、\r、\n、\xXX（16進数表記でのエスケープ）、\uXXXX（Unicodeエスケープ）以外のエスケープはエスケープ文字を含んだ文字列として取得されるという事が判明した。例えば\tはタブ文字ではなく"\t"になるし、\/は"\/"になる。これは予想外だった……

で、このあたりの挙動を再現するコードをゼロから書こうとしたら死ねると思ったので、結局、prefreadをまるごとJavaScriptに移植する事にした。といってもJavaScriptの文法はCに近い（らしい）ので、コピペして少し書き換えたという感じ。

UxU自体のライセンスはGPLなんだけど、ソースコードとして入手する限り、このファイルのライセンスは元バージョンと同じMPL/GPL/LGPLとして使えるはずなので、まぁ、そんなに使い出はないと思うけど使いたい人がいたらどーぞ。

テキストリンク 3.0.2009021801 - Feb 18, 2009

直った直った書いてたけど見落としがありましたごめんなさい。

コンテキストメニューを開くと固まる、という極端なケースの事例としてGMailでの現象を見て、他の所で起こってるらしいコンテキストメニューがらみの問題もこれ（スタイルシートに対してマッチングを行って激遅になってる）に違いない！と思い込んでしまってたんだけども、それ以外に、テキストノードが細かく分割されてる場面でも超スローになってしまうことがあることに、今朝やっと気付きました。

修正箇所を見ると分かるけど、何でか手抜きでXPath式の評価をループごとに毎回行うように書いてたせいで、表みたいにテキストが細かく分割されてる場面でXPath式の評価が無駄に何度も行われてしまい、それで時間を食ってた。式の評価を最初の1回だけにしたら、場合によっては100倍くらい速くなった。正直、document.evaluate()の実行コストを甘く見てた。

実に恥ずかしいミスですね。

テキストリンクをテキスト入力欄の中でも使えるようにしてみた - Feb 16, 2009

テキストリンク 3.0.2009021601で、inputやtextareaの中のURI文字列も処理できるようにしてみた。といっても、テキスト入力中にダブルクリックするだけで開かれるとかそんなのはウザすぎるので、あくまでURI文字列選択中にコンテキストメニューを開いた時だけの機能だけど。ブログとか日記とか書いてる途中でふと確認したくなった時、なんかに使えるんじゃないかと思う。

DOM2 RangeのcompareBoundaryPointsをnsIDOMNSEditableElementの編集領域の中のRange同士の間で使うと、何故だかNS_ERROR_DOM_WRONG_DOCUMENT_ERR例外が発生してしまったので、仕方ないからnsIDOMNSRangeのcomparePointで解決するようにしてみた。独自仕様な上にどうにも動作が怪しい感じなので、できればcompareBoundaryPointsだけで済ませたかったんだけど、なかなかうまくいかない。

GMailでコンテキストメニューが固まる問題は、本文だけじゃなくヘッダ領域の中のstyle要素の内容までURI文字列の検索対象にしてしまってたせいだった（全面リライトにあたって、DOM3 XPathで代用できそうな所を片っ端からDOM3 XPathに置き換えたんだけど、XPath式の評価結果が書き直し前と違ってたことに気付いてなかった）。スタイル宣言が全部URI文字列らしき物として検出されてしまって、それで無限ではないんだけど数千回のループが発生して、途中で処理を打ち切られてたという感じ。XPath式を工夫してbodyの中だけを検索対象にするようにしたら直った。

この辺の修正に際してもまたテストを書き足した。こんな感じでテストが充実してくれば、多分、将来的にはregressionは減る方向に向かうと思うんだけど……

テキストリンク 3.0 - Feb 14, 2009

テキストリンク更新した。1つ前のバージョンから、Firefox 1.5等の古い奴はサポートしなくなってる。

設定ダイアログもprefwindowベースで書き直した（今まではSeamonkeyと共通で動作させるためにdialogベースで自力で書いてた、というかSuite時代はそうせざるを得なかった）ので、多分Mac OS Xで起こってるという設定まわりの問題は解消されてるんじゃないかと思うんだけど……どうだろう。

バージョン番号は上がったけど、機能的には大して変わってない。新機能と言えばせいぜい、選択範囲のURI文字列をまとめてコピーする機能くらいだ。内部的には、Firefox 3以降での「複数の選択範囲（ページ内をCtrl-ドラッグすると離れた位置に飛び飛びで選択範囲を作れる）」への対応のために抜本的な改修を行ったんだけれども、それって多分使う側にとっては割とどうでもいいことだろうなあ。

あと、このバージョンからガッツリ自動テストするようにした。

ところで、公開中のアドオンのいくつかについて「とっととFirefox 3.1対応しろやゴラァ」メールがMozilla Product Teamから届いた。「対応しないとお勧めリストから消すぞゴラァ」みたいな。

• テキストリンク→もう対応した
• タブカタログ→3.1でCtrlTabが入るものと思ってたからもう完全放置気分なんですが……
• 2ペインブックマーク→もう対応した、ついでにFirefox 2以前も切った
• Popup ALT Attribute→対応バージョン情報の書き換えだけでよさげ
• XHTMLルビサポート→対応バージョン情報の書き換えだけでよさげ
• ラインマーカー→対応バージョン情報の書き換えだけでよさげ
• 巻き戻し/早送りボタン→対応バージョン情報の書き換えだけでよさげ

コンテキストメニュー拡張の機能を減らした - Dec 02, 2008

コンテキストメニュー拡張を久しぶりにアップデートした……けどアップデートの内容は実質デグレードみたいなものだ。外部アプリケーションでソースを表示する機能、mailto:のリンクをメールソフトやWebメールのサービスに渡す機能、ユーザスタイルシートを編集する機能、任意のスタイルシートを登録して切り替える機能、あたりをゴッソリ削除した。

• ソースを他のアプリケーションで開く機能はFirefox 3本体にあるし、ソース表示タブあたりを使えばGUIで設定できる。もはや用済み。
• mailto:の処理をコントロールする機能もFirefox 3に標準で付いてる。オプション→プログラム→mailtoで、外部アプリケーションを指定することもYahoo!メールやGmailを指定することもできる。もはや用済み。
• スタイルシート関係の機能は、そもそもまともに動かなくなってからだいぶ経ってた。今ではStylishもあればuserstyle.orgもあり、そっち使った方が絶対にいい。

できれば無駄にRDFを使ってるバックエンドも全部捨てたいんだけど、これを捨てると旧版の設定が全部失われてしまうことになるというのが痛い。

Minefield 3.1b3preの、タブのドラッグ＆ドロップへの対応 - Dec 02, 2008

ツリー型タブとマルチプルタブハンドラで、Firefox 3.1からの「ウィンドウ外にタブをドロップしたら新しいタブを開く」機能に対応した。子タブを持っているタブをウィンドウ外にドロップしたら子孫タブまで含めて新規ウィンドウに分離され、複数のタブを選択してウィンドウ外にドロップしたら選択されたタブすべてが新規ウィンドウに分離される。という感じ。ちょっと前の分割ブラウザの更新もこれに関係してる。

Minefield 3.1b3preでは、ブラウザのタブをドラッグした時はapplication/x-moz-tabbrowser-tabという型のデータがドラッグデータのリストの先頭に加わるようになった。今までは、ドラッグセッションの「ドラッグを開始した要素」をその都度参照していたようだったので、やっとまともな実装になったなーという感じだ。

分割ブラウザやツリー型タブでは、この型のデータも受け入れ可能なように修正した。そうしておかないと、「application/x-moz-tabbrowser-tab型のデータはドロップできないんだな」と判断されて、タブをタブバーや分割された領域にドロップできなくなってしまう。

Minefield 3.1b3preでの「ウィンドウ外へのドロップ」はどのように実装されているのかを調べてみた所、dragendイベント（ドラッグが終了した時に、「ドラッグが開始された要素」で発行されるイベント）のタイミングで、ドロップ操作に失敗した（ドラッグ操作終了時点でポインタの状態が「ここにはドロップできません」のポインタになっている）場合には「ウィンドウ外へドロップされた」と判断して、新しいウィンドウを開きそのタブとドラッグ元のタブを入れ替える、という風にして実現していた。

この時ドラッグ元のウィンドウでは、tabbrowser要素の_replaceTabWithWindow()メソッドにおいて、新規ウィンドウの第1引数にtab要素を渡して開くだけで処理を終えている。そこから先の「ドラッグ元のタブと新しいウィンドウの内容の入れ替え」は、新しく開かれたウィンドウの初期化処理（BrowserStartup()関数）の方でやってる。

なので、ツリー型タブとマルチプルタブハンドラでは、その両方の処理に割り込むようにした。_replaceTabWithWindow()を呼び出している_onDropEnd()メソッドで、_replaceTabWithWindow()メソッドを呼ぶ直前に割り込んで、切り離されようとしているタブの収集結果がそのウィンドウのタブ全部だった場合には操作をキャンセルしている。また、BrowserStartup()の方では、ウィンドウの第1引数がtab要素だった場合はまずツリー型タブとマルチプルタブハンドラに処理を渡して、何も行われなければ（渡されたタブが子タブを持っておらず、選択もされていないならば）Firefox本来の処理（単一タブの切り離し）に入る、という感じにしている。

ドラッグ元のタブ自身の上にドロップした時までウィンドウの切り離しになってしまうなど、Minefield 3.1b3preの当該機能自体がまだまだ作り込みが甘い感じなんだけど、そういう所にまで手を出すと収拾がつかなくなる＆Firefox 3.1正式版までの間に手を入れられたらまた作業のやり直しになるので、そこら辺は基本的に放置してる。ただし複数のタブを同時に閉じようとした時の問題だけは、閉じるのに失敗したタブが永遠に閉じられなくなるなどの致命的な問題を引き起こすので、ツリー型タブの側で対処している（提出したパッチと同じ事をやってる）。

ルーラーバーでエンコーディングの違いに対応したよ - Dec 01, 2008

英語で書かれた障害報告のメールに返信する時にルーラーがひどくずれていたのが気になってたけど放置してた件について、ルーラーバー 0.3.2008120101で修正した。

今まで、ルーラーの表示サイズの基準には編集領域のdocument.documentElementのfont-sizeを使ってたけど、こちらはエンコーディングが変わっても値が変化しない。それに対して、document.bodyのfont-sizeは、エンコーディングごとのフォントサイズの違いの影響を受ける。ということでbodyの方の値を参照するようにしたら、ルーラーの間隔はおおむね正しいものになるようになった。

ただ、これでもカーソル位置の強調表示のずれは残る。フォントサイズだけでなくフォント自体もエンコーディングによって変わる可能性があり、フォントサイズだけ合わせても、実際の編集領域とカーソル位置検出用の非表示のフレームとでフォントが違ったら、ピクセル単位で位置を拾った時に微妙にずれが発生する可能性がある。そこで、非表示のフレームの方にもエンコーディングの変化を適用させるために、SetDocumentCharacterSet()のタイミングで非表示のフレームの方のエンコーディングも変更するようにした。エンコーディングの動的な変更の方法はこんな感じ。

// this.calculator は非表示のフレームのbrowser要素
var docCharset = this.calculator.docShell
      .QueryInterface(Components.interfaces.nsIDocCharset);
docCharset.charset = aCharset;
var webNav = this.calculator.webNavigation;
webNav.reload(webNav.LOAD_FLAGS_CHARSET_CHANGE);
var self = this;
this.calculator.addEventListener('DOMContentLoaded', function() {
   self.calculator.removeEventListener('DOMContentLoaded', arguments.callee, false);
   // 読み込みが終わった段階でルーラーの表示を更新する（カーソル位置の検出をやり直す）
   self.updateRulerAppearance();
}, false);

最後にリロードしないと表示が変わらない、のかな？（リロードしなかった場合の挙動については未検証）

ソース表示タブ 0.3.2008111401でリンクの遷移とメニュー項目のミドルクリックに対応したよ - Nov 14, 2008

ソース表示タブ更新しました。メインはMinefield 3.1b2preで使えるようになった「ページのソース」内のリンクへの対応です。タブ内でソースを表示している時にソース内のリンクを辿った場合、普通にフレームを使ったページでフレーム内のページを移動したのと同じような動作になるようですが、タブのタイトルやURIの表示欄を遷移に合わせて更新するように修正しました。リンクのミドルクリックから別のタブでソースを開くという操作にも対応してます。

あと、ソースをタブで開く設定にしてる時にたまにデフォルトの動作（ウィンドウでソース表示）をちょっとだけ使いたい、というケースがあったので、メニューの「ページのソース」や「ページのソースを表示」をミドルクリックまたはCtrl-クリックした時に設定を反転した動作を行う、という機能も付けてみました。挙動の変化の説明は文章にするとわかりにくいので、以下に表を置いておきます。

ツリー型タブ 0.7.2008110801で最大化の問題を修正したよ - Nov 08, 2008

表題の通り。最大化状態でFirefoxを終了して次にFirefoxを起動した時に、最大化が勝手に解除されてしまう問題。ブラウズ領域の描画内用が変になることがある問題というのが発生してて、ウィンドウをリサイズしたら直るようだったので1ピクセルだけウィンドウの大きさを変えてまた元に戻すというコードを入れてみてたんだけど、最大化状態でやると最大化が解除されてしまうということに気付かないままリリースしてしまってました。

みんな最大化って結構使ってるんですね……ということを、このバグの報告が大量に来たことで実感した次第です。

XUL/Migemo 0.11.5でMinefield 3.1b2preのタブ検索に対応したよ - Nov 08, 2008

表題の通り。昨日と今日とでガラッとUIが変わったりしてカオスな事この上ないMinefield 3.1b2preですが、最終版まで残るものと踏んで、タブの一覧を表示した時に絞り込みを行う検索欄でMigemo検索できるようにしました。ページ内検索の物とは異なり、スマートロケーションバーと同様にスペース区切りで複数語句のAND検索になります。入力からそれに対応する正規表現を生成する部分の処理はスマートロケーションバーの物を汎用化して使っているので、語句の頭に「-」を付ければNOT検索もできます。

で、その関係でpIXMigemoインターフェース（XMigemoCore）に新しくいくつかメソッドが加わりました。以下、IDL定義から抜粋。

AString getRegExpFunctional(
   in AString input,
   out AString termsRegExp,
   out AString exceptionsRegExp
);
attribute boolean andFindAvailable;
attribute boolean notFindAvailable;
boolean isValidFunctionalInput(in AString input);
AString trimFunctionalInput(in AString input);

getRegExpFunctional()に「nihon go -hoge」という風な文字列を渡すと、nihonとgoをローマ字入力として解釈した結果でAND検索を行うための正規表現が返ってきます。第2引数に渡したオブジェクトのvalueプロパティには、AND検索ではなくOR検索のための正規表現が格納されます（これを使うと、検索にマッチした単語を取り出すことができる）。第3引数に渡したオブジェクトのvalueプロパティには、NOT検索で「これにマッチしたら除外する」という用途に使う正規表現が格納されます。先の例だと「hoge」をローマ字入力として解釈した結果の正規表現ですね。

trimFunctionalInput()メソッドは、例えば「nihon go -」という風な（NOT検索の入力中と思われる）文字列を渡すと、前後の空白と最後のハイフンを取り除いた結果を返します。NOT検索が無効な時は、前後の空白だけが取り除かれます。今の所はそれだけしかしません。

isValidFunctionalInput()は、trimFunctionalInput()やgetRegExpFunctional()に渡してMigemo検索するに値する内容かどうかを判定します。このメソッドがfalseを返した場合はMigemo検索のための処理を丸ごとスキップする、という風な感じで使います。

タブの一覧の絞り込み部分のコード（filterListFromInputメソッド）が、まさにこれらの実際の利用例ということになります。自分のアドオンやらuserChrome.jsやらで使ってみたい人は参考にしてください。

他の目につく改良点として、スマートロケーションバーの検索処理を改善しました。というか修正しました。元々スマートロケーションバーでは、例えば「moz」と入力して出てきた候補から「mozilla.jp」を選択した場合、2度目以降はその候補が真っ先に表示されるし、同様に「mozilla.gr.jp」や「addons.mozilla.org」なども選択したことがある場合には選択回数が多い物から順に表示される、という仕様になってるんですが、これを再現するためのSQL文を書き間違えてて（MAX関数をJavaScriptのMath.max()みたいなものと勘違いしてた）、同じ項目を何度選んでも表示の順位が上がらないという状態になってました。スマートロケーションバーが全然スマートじゃなくなってたという……