たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
コンテキストメニュー拡張を久しぶりにアップデートした……けどアップデートの内容は実質デグレードみたいなものだ。外部アプリケーションでソースを表示する機能、mailto:のリンクをメールソフトやWebメールのサービスに渡す機能、ユーザスタイルシートを編集する機能、任意のスタイルシートを登録して切り替える機能、あたりをゴッソリ削除した。
できれば無駄にRDFを使ってるバックエンドも全部捨てたいんだけど、これを捨てると旧版の設定が全部失われてしまうことになるというのが痛い。
ツリー型タブとマルチプルタブハンドラで、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正式版までの間に手を入れられたらまた作業のやり直しになるので、そこら辺は基本的に放置してる。ただし複数のタブを同時に閉じようとした時の問題だけは、閉じるのに失敗したタブが永遠に閉じられなくなるなどの致命的な問題を引き起こすので、ツリー型タブの側で対処している(提出したパッチと同じ事をやってる)。
英語で書かれた障害報告のメールに返信する時にルーラーがひどくずれていたのが気になってたけど放置してた件について、ルーラーバー 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);
最後にリロードしないと表示が変わらない、のかな?(リロードしなかった場合の挙動については未検証)
UxU(UnitTest.XUL)を利用したFirefoxアドオンのデバッグの例 - ククログ(2008-11-17)
XUL/Migemo 0.11.7での修正内容が典型的な「自動テストを使ったデバッグ」だったので、UxUのチュートリアルを兼ねて、会社のサイトの方に書いてみました。UxUの解説って言うよりは、テスト駆動開発自体の解説という気もしますが。
リンク先に解説してるのはpXMigemoFindのfindFirstVisibleNodeメソッドだけのデバッグ話ですが、実際にはこのメソッドはだいぶ根幹に関わる物で、このメソッドの挙動の変更によって他の機能に色々と影響が出る可能性がありました。が、他の挙動に関しては一通り自動テストを作成済みだったために、後退バグの発生で収拾不能な事態に陥るということを恐れずに安心して修正に取り組むことができた、というまさに自動テスト様々な事例だったということも忘れずに付け加えておきたい所です。
XUL/Migemoの動作で怪しい所を見つける→再現条件確定→その条件下でのテストを行うためのUxUのテストケースを作成→何かちゃんと動かない→UxUのバグ発見→抜本的修正開始→途中で疲れて寝る→抜本的修正続き→やっとチェックイン→XUL/Migemoのテストを書く気力がなくなってる→それでもめげずにテスト書き再開→UxUの別の問題発覚→心が折れかける(今ここ)
ソース表示タブ更新しました。メインはMinefield 3.1b2preで使えるようになった「ページのソース」内のリンクへの対応です。タブ内でソースを表示している時にソース内のリンクを辿った場合、普通にフレームを使ったページでフレーム内のページを移動したのと同じような動作になるようですが、タブのタイトルやURIの表示欄を遷移に合わせて更新するように修正しました。リンクのミドルクリックから別のタブでソースを開くという操作にも対応してます。
あと、ソースをタブで開く設定にしてる時にたまにデフォルトの動作(ウィンドウでソース表示)をちょっとだけ使いたい、というケースがあったので、メニューの「ページのソース」や「ページのソースを表示」をミドルクリックまたはCtrl-クリックした時に設定を反転した動作を行う、という機能も付けてみました。挙動の変化の説明は文章にするとわかりにくいので、以下に表を置いておきます。
設定 | 通常の操作での動作 | ミドルクリックで反転された動作 |
---|---|---|
ソースを別ウィンドウで開く | ソースを別ウィンドウで開く | ソースをタブで開く |
ソースをタブで開く | ソースをタブで開く | ソースを別ウィンドウで開く |
外部アプリケーションで開く | 外部アプリケーションで開く | ソースを別ウィンドウで開く |
今まで全然知らなかったんだけど、vimperatorでXUL/MigemoのAPIを使ってタブの切り替えやヒントモードを強化するなんてことをやってる人がいたんだ。(←って、分かったような書き方をしてるけどvimperatorの事は全然分かってません……)
その関係でいくつかページを渡り歩いてたら、XUL/Migemoのバグって話題が出ていて、なぬ!と思ってさらに辿ってみた所、半角括弧がらみの問題のことらしい。あーこの辺ちゃんと見直さないままずっとここまで来てたんですよね……UxU用のテストも基礎部分の単体テストはさっぱり手つかずのままだったし(ぉぃ)。ということで本腰入れてテスト書いて、潜在してたバグを潰し始めました。でもまだまだ見落としがありそう。
ツリー型タブとクリック証券のFXツールバーが衝突しているという話を見かけたので調べてみたんだけど、だいぶお手上げです。
リバースエンジニアリング禁止とあったけどべつに僕はこれを利用するつもりも使用するつもりもないのであくまで自作アドオンとの競合の原因を調査するために難読化されたコードを頑張って解読してみたところ、FXツールバーは非同期処理のための便利メソッドを持ってるくせに何故か初期化の時は同期処理にしているという事が分かった。何故そんなところで手を抜くんだ……
サーバからの設定の読み込みを非同期で行って、設定の読み込み完了後に初期化処理の続きを行うようにすれば、この問題は解消されると思うんだけど。ツリー型タブ以外にも物によっては衝突する可能性があるし、向こうの方で対処してくんないかなあ。望み薄かなあ。一応問い合わせ先のアドレス宛にメールしてみたけど……
続報。返信があり、初期化処理を非同期で行うように改良された新バージョンがもうすぐ公開されるとのことです。反応はやっ!(僕がメールするより前から準備してたっぽい?)
会社サイトのブログの方で解説を書くつもりですが、UxU新バージョン(0.5.0)を公開しました。日本時間10月30日の昼下がり、太平洋標準時で29日の肉の日リリースです。変更点はMozilla Add-onsのバージョン詳細の方を見てください。
自分自身がサーバソケットの方を使ってなかったのでMozRepl互換のサーバ機能の方がだいぶ長らく死亡してたみたいなんですが、今回プロファイルを指定してテストを実行する機能を作るにあたり、新たに起動された子プロセスと親プロセス側でテストの実行結果や中止の命令とかを通信しあうために、UxUサーバで使われていた機能をブラッシュアップして流用するようにしたため、ぶっ壊れていた所がだいぶ直りました。今後はサーバ周りの実装も気をつけて見るようになると思いますので、ぶっ壊れっぱなしのまま放置ということは減るんじゃないかと思います。多分。
ところで、子プロセス起動してうんたらかんたらということができるようになったということは、FirefoxやThunderbirdの上で動かすことにこだわらなくてもいいようになった(必要に応じてそれらを呼び出せば済む)という事で、やる気次第ではXULRunnerアプリケーション化という道もあり得るかもしれませんね。