Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 17/248: « 13 14 15 16 17 18 19 20 21 »

XUL/Migemoで、非表示の要素の中にマッチする文字列があったときに検索結果がおかしくなる問題で悩んでる - Dec 05, 2008

掲示板の方で障害報告を受けていた、正規表現にマッチするはずなのに強調表示される物とされない物があるという問題。原因を色々調べてみたら、非表示の要素が問題を引き起こしていた。

<fieldset>
<legend style="display:none">b</legend>
<p>a b a c</p>
</fieldset>

例えばこんな箇所を検索対象にして、a|bという正規表現で検索するとする。

XUL/Migemoはまず一旦検索対象の範囲をDOM Rangeで取得して、文字列に変換し、それに対して正規表現のマッチングを行う。この場合、Rangeからは「b a b a c」という風な文字列が得られ、最初にマッチした「b」がヒット箇所ということになる。

次に、この「実際にヒットした文字列」を使ってFirefox自身の持つ検索機能を呼ぶんだけど、ここで問題が起こる。Rangeの文字列化では要素が表示されてるかどうかというのは考慮されないんだけど、nsIFindのRange内検索では、ヒット箇所が非表示の要素の中だった場合はヒットしなかったものとして次候補を探してしまう。上記の例では、非表示のlegend要素の中に「b」という文字列を見つけても、非表示だからということでスルーされてしまい、実際には次のp要素内の「b」という文字列の方にヒットしてしまう。

XUL/Migemoで次候補を検索すると、次の(2つ目の)「a」にはヒットする。さらに次候補を検索すると、文書の終了に達して文書先頭から検索し直されるのだけれども、この時も上記のような事が起こって、p要素内の1つ目の「a」ではなくp要素内の「b」がヒットする。よって、普通の前方検索を行っている間は永久に、p要素内の1つ目の「a」にはマッチしないという現象が起こる。

Rangeを文字列化する時に、非表示の要素を除外できればいいんだけど……

ちなみに現在のところ、Rangeを文字列化する時は、DOM3 XPathを使ってscript要素などを検出してそこを避けるように文字列化してるんだけど、要素の表示・非表示をキーにしようとするとDOM2 TraversalのTreeWalkerを使わないといけないと思う。TreeWalkerではすべての要素ノードに対してJavaScriptの関数呼び出しと条件判定が行われるので、長いページだとヤバイくらいに速度低下が起こりそう……という懸念があって、手を出せずにいる。

追記。実際にそのように実装して試してみたところ、確かに正しく検索できるようにはなるんだけど、Rangeを文字列化する処理自体が10倍遅くなった。これはまずいなあ。

コンテキストメニュー拡張の機能を減らした - 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.documentElementfont-sizeを使ってたけど、こちらはエンコーディングが変わっても値が変化しない。それに対して、document.bodyfont-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);

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

UxUを使った、自動テストを伴うデバッグ手法の実践 - Nov 18, 2008

UxU(UnitTest.XUL)を利用したFirefoxアドオンのデバッグの例 - ククログ(2008-11-17)

XUL/Migemo 0.11.7での修正内容が典型的な「自動テストを使ったデバッグ」だったので、UxUのチュートリアルを兼ねて、会社のサイトの方に書いてみました。UxUの解説って言うよりは、テスト駆動開発自体の解説という気もしますが。

リンク先に解説してるのはpXMigemoFindのfindFirstVisibleNodeメソッドだけのデバッグ話ですが、実際にはこのメソッドはだいぶ根幹に関わる物で、このメソッドの挙動の変更によって他の機能に色々と影響が出る可能性がありました。が、他の挙動に関しては一通り自動テストを作成済みだったために、後退バグの発生で収拾不能な事態に陥るということを恐れずに安心して修正に取り組むことができた、というまさに自動テスト様々な事例だったということも忘れずに付け加えておきたい所です。

よくある風景 - Nov 15, 2008

XUL/Migemoの動作で怪しい所を見つける→再現条件確定→その条件下でのテストを行うためのUxUのテストケースを作成→何かちゃんと動かない→UxUのバグ発見→抜本的修正開始→途中で疲れて寝る→抜本的修正続き→やっとチェックイン→XUL/Migemoのテストを書く気力がなくなってる→それでもめげずにテスト書き再開→UxUの別の問題発覚→心が折れかける(今ここ)

XUL/Migemoとvimperatorと単体テスト - Nov 10, 2008

今まで全然知らなかったんだけど、vimperatorでXUL/MigemoのAPIを使ってタブの切り替えヒントモードを強化するなんてことをやってる人がいたんだ。(←って、分かったような書き方をしてるけどvimperatorの事は全然分かってません……)

その関係でいくつかページを渡り歩いてたら、XUL/Migemoのバグって話題が出ていて、なぬ!と思ってさらに辿ってみた所、半角括弧がらみの問題のことらしい。あーこの辺ちゃんと見直さないままずっとここまで来てたんですよね……UxU用のテストも基礎部分の単体テストはさっぱり手つかずのままだったし(ぉぃ)。ということで本腰入れてテスト書いて潜在してたバグを潰し始めました。でもまだまだ見落としがありそう。

FXツールバー - Nov 10, 2008

ツリー型タブクリック証券のFXツールバーが衝突しているという話を見かけたので調べてみたんだけど、だいぶお手上げです。

  • 原因は、クリック証券のFXツールバーが、初期化処理の中でXMLHttpRequestの同期読み込みを使っているせいである。
    • 同期読み込みを行っている間、ツリー型タブを含む他のアドオンの処理がすべてストップしてしまう。
    • ツリー型タブはセッション復元のイベントを捕捉してツリー構造を復元している。正常な状態では、こうなっている。
      1. ツリー型タブの初期化処理が始まる。セッション復元関係のイベントの監視が始まる。
      2. セッション復元関係の処理が行われる。
      3. ツリー型タブがセッション復元関係のイベントを捕捉し、ツリー構造を復元する。
    • しかしFXツールバーが入っている場合はこうなる。
      1. FXツールバーの初期化処理が始まる。同期読み込みのために処理が止まる。
      2. セッション復元関係の処理が行われ、完了する。
      3. 同期読み込みが完了し、FXツールバーの初期化処理が終わる。
      4. ツリー型タブの初期化処理が始まる。セッション復元関係のイベントの監視が始まる(が、もはや手遅れ)。
  • FXツールバーの初期化処理を書き換えてみようと思ったけど、変数スコープの関係で、ツリー型タブの中からFXツールバーの初期化処理を書き換えたら全く動かなくなってしまう。
  • FXツールバーの初期化処理が走る前にセッション復元イベントの捕捉を開始して、ツリー型タブの初期化が終わる前に起こったイベントはすべてキューに溜め込み、ツリー型タブの初期化が終わった後でそのキューを処理する、という風にしてみたけど、タイミング次第ではまだ復元に失敗する。

リバースエンジニアリング禁止とあったけどべつに僕はこれを利用するつもりも使用するつもりもないのであくまで自作アドオンとの競合の原因を調査するために難読化されたコードを頑張って解読してみたところ、FXツールバーは非同期処理のための便利メソッドを持ってるくせに何故か初期化の時は同期処理にしているという事が分かった。何故そんなところで手を抜くんだ……

サーバからの設定の読み込みを非同期で行って、設定の読み込み完了後に初期化処理の続きを行うようにすれば、この問題は解消されると思うんだけど。ツリー型タブ以外にも物によっては衝突する可能性があるし、向こうの方で対処してくんないかなあ。望み薄かなあ。一応問い合わせ先のアドレス宛にメールしてみたけど……

続報。返信があり、初期化処理を非同期で行うように改良された新バージョンがもうすぐ公開されるとのことです。反応はやっ!(僕がメールするより前から準備してたっぽい?)

UnitTest.XUL 0.5.0 - Oct 30, 2008

会社サイトのブログの方で解説を書くつもりですが、UxU新バージョン(0.5.0)を公開しました。日本時間10月30日の昼下がり、太平洋標準時で29日の肉の日リリースです。変更点はMozilla Add-onsのバージョン詳細の方を見てください。

自分自身がサーバソケットの方を使ってなかったのでMozRepl互換のサーバ機能の方がだいぶ長らく死亡してたみたいなんですが、今回プロファイルを指定してテストを実行する機能を作るにあたり、新たに起動された子プロセスと親プロセス側でテストの実行結果や中止の命令とかを通信しあうために、UxUサーバで使われていた機能をブラッシュアップして流用するようにしたため、ぶっ壊れていた所がだいぶ直りました。今後はサーバ周りの実装も気をつけて見るようになると思いますので、ぶっ壊れっぱなしのまま放置ということは減るんじゃないかと思います。多分。

ところで、子プロセス起動してうんたらかんたらということができるようになったということは、FirefoxやThunderbirdの上で動かすことにこだわらなくてもいいようになった(必要に応じてそれらを呼び出せば済む)という事で、やる気次第ではXULRunnerアプリケーション化という道もあり得るかもしれませんね。

Page 17/248: « 13 14 15 16 17 18 19 20 21 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき