この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2010年3月)

2010年3月6日

Bug-org 545602 Unify the event listeners for editor 初回投稿日時: 2010年03月06日14時20分07秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010030600
リンク元: 0件
SNS: (list)

色々あって一ヶ月ぶりの修正になってしまいました。

nsPlaintextEditorは、nsEditorEventListenersで6個のリスナーを作成し、nsHTMLEditorはさらにそのうちのひとつをnsHTMLEditorMouseListenerで継承して利用していました。

なぜ、6個のリスナーに分離して作成されたのか分かりませんが、このためにnsEditorはポインタを6つも保持する必要があり、6回、リスナーのインスタンスを生成する必要があります。また、リスナー間で共通のメンバも重複して保持しないといけないため、非常に無駄の多い形になっていました。

このバグの修正でnsPlaintextEditor用の6つのリスナーは、nsEditor依存のリスナーとして統合、再設計しています。これによりBug-org 389372Bug-org 467715の修正が容易になってるかもしれません。

2010年3月10日

Bug-org 550772 fallback pref font handling for CJK fonts is broken 初回投稿日時: 2010年03月10日15時19分39秒
最終更新日時: 2010年03月10日15時20分08秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010031000
リンク元: 0件
SNS: (list)

TrunkでMacのUIが中国語フォントで表示されていたバグです。

チベット語をUIに追加したことによるregressionでした。

定数が31までしか使っていなかったことからビットマスクの桁として利用していた箇所があり、これが今回、32まで必要になったことにより、破綻してしまっていました。

こういうバグはレビューでは見つけにくいので、ビットマスクとして利用する定数には、diffファイルに表示されるように、32付近にコメントをしっかりとつけておくしか再発防止にはつながらないんではないかと思います。

2010年3月11日

Bug 5291 WM_VSCROLL、WM_HSCROLLに対応すべき 初回投稿日時: 2010年03月11日18時08分28秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010031100
リンク元: 0件
SNS: (list)

ようやく対応が終わりました。

この修正で、WM_*SCROLLを利用したキャプチャソフトを利用してFirefoxでもページをキャプチャすることができます。

また、マウスドライバがホイール回転時にこのメッセージを送信している場合、about:configmousewheel.emulate_at_wm_scrollをtrueにすると、Gecko内部でマウスホイールメッセージと同様に扱い、DOMMouseScrollイベントも生成するようになります。

2010年3月17日

第二京阪開放イベントに行ってきた 初回投稿日時: 2010年03月17日00時14分13秒
最終更新日時: 2010年03月17日01時48分41秒
カテゴリ: 旅行 雑談
固定リンク: id=2010031700
リンク元: 0件
SNS: (list)

風邪で割と体調悪いなか、無理矢理行ってきました。

門真IC登り口のプレート

門真ICの登り口のプレートです。

門真側の国道一号バイパスの終点(大阪向き)

門真側の国道一号バイパスの終点の大阪向きの写真です。中環との交差点ですね。

直進3レーン、右折2レーン、さらに左折可のレーンが一番左のレーンから分岐してました。これほどの需要が見込まれているのに、花博通りと内環の交差点、内環と阪奈(府道8号)、さらに国道一号、阪奈、今里筋の交差点である蒲生四が増加する車を捌けるのか気がかりです。理想的には森小路まで花博通りをぶち抜くしか無いんでしょうね。

門真側の国道一号バイパスの終点(京都向き)

同じ場所で京都を向くとこんな感じの案内になります。本線は2レーン。左折可からの合流と直進から側道への車のポジションチェンジがスムーズにできないとすぐに詰まりそうな感じでした。

電光掲示板

俯瞰

俯瞰だとこんな感じです。終了間際に行ったのにまだまだ人が多かったです。

高速から門真市が見下ろせる

市街地では防音壁が硝子張りなので町並みがよく見えます。

第二京阪が開通すれば守口⇔枚方間の慢性的な渋滞が解消に向かうでしょうし、今、私の家から京都駅まで片道2時間はかかるのが30分程度に短縮されます(どちらも高速利用時)。

ちなみに、この第二京阪、大阪市街地(門真市と大阪市の境界)と京都市街地(京都市伏見区)を初めて直結する高速道路だったりします。日本で隣接している二大都市の市街地が直通してなかったって知ってました? (吹田経由で近畿道を使えばそうとも言い切れませんがやや遠回りな上に、渋滞も多く、あまり便利ではないです。)

たまに車乗らない人がもう道路は要らないなんて言ってることがありますが、まだまだ必要なところは必要なんですよね、田舎に限らず。

2010年3月22日

Bug-org 528396 Create XP level IME transaction tests 初回投稿日時: 2010年03月22日13時15分26秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010032200
リンク元: 0件
SNS: (list)

IMEのXP部分の自動テストの作成バグです。テスト用APIの作成方法を巡ってかなり長時間にわたる作業になりましたが、ようやく完成しました。

早速、チェックイン直前のビルド確認でBug-org 544852によるregressionがたまたま発生していたのを見つけました。3/15あたりのビルドから、数日間、ブックマークのパネルや、iframe上で候補ウインドウや、ATOKのナビバーがずれるバグを見た人が居たら、そのバグです(ちなみに報告はありませんでした)。

このバグのチェックインで同時にこのregressionも修正しています(そうしないとテストにパスしないので)。

Bug-org 520732 Separate IME related code to another file from gtk2/nsWindow.cpp 初回投稿日時: 2010年03月22日13時21分26秒
最終更新日時: 2010年03月22日13時46分33秒
カテゴリ: modest Mozilla Core バグ修正
固定リンク: id=2010032202
リンク元: 0件
SNS: (list)

GTK2のIME関連のコードをnsWindowから分離しようというバグです。

ようやく修正が終わりました。修正時にはフォーカスハンドリングまわりで、理論上存在したバグ(実際に何かが起きるのか、どうやって再現するのか、そもそも再現する環境があるのかは不明)なものをいくつか修正しています。

最近、GTK2のIMEまわりのコードは私のレビューを通らずにN8x0、もしくはN900のために修正される危険が高かったので、これでコードのオーナーシップが多少は明確になったと思います。

また、この修正により、ログをとることが可能になりました。ログの取り方はmodestの記事を参照してください

Bug-org 283136 preedit/candidate window position should follow the cursor position for Chinese/Japanese/Korean input methods 初回投稿日時: 2010年03月22日13時28分57秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010032203
リンク元: 0件
SNS: (list)

変換中の候補ウインドウが、日本語のIMEだと未確定文字列の先頭で常に表示されたり、中国語のIMEだとそもそもデタラメな位置に表示されていたというバグです。

Bug-org 520732の修正によって同時に修正されています。新しい設計により、Windowsと同様に未確定文字列の中でも選択中の文節を位置の基準とするようになりました。また、中国語のIMEだとpreedit_changedシグナル自体が発生しないので、新たにpreedit_startシグナルも監視するようにし、このイベント時にも候補ウインドウ位置を設定するように修正しました。

2010年3月23日

Re: ブラウザを窓から投げ捨てたくなるバグのその後2 初回投稿日時: 2010年03月23日14時08分09秒
カテゴリ: Mozilla Core
固定リンク: id=2010032300
リンク元: 2件
SNS: (list)

結構貢献してくださってるのでありがたいんですが、このバグに関してはいい加減に理屈を理解してもらいたいです。開発陣は変てこりんな理屈を付けて動かなくするんだろうなとか悪意をもって言われるのは、かなり不愉快ですし、これ以上、ずれた批判をされても時間の無駄です。ですので、ここに理屈と、Geckoの設計思想を紹介しておきます。

WindowsのGUIアプリのプログラミングはウインドウプロシージャにイベントに相当するメッセージが送られてくるので、これに対して適切なリアクションをする、という形になります。マウスホイールのメッセージである、WM_MOUSEWHEELWM_MOUSEHWHEELメッセージは通常、フォーカスを持ったウインドウ(SDK用語で言うウインドウ)に対して送信されます。通常、というのは多くのドライバで採用されている方式であるということで、マウスドライバによってはカーソル位置を尊重することもできると思います。

Webブラウザはコンテンツに対してひとつのウインドウを生成し、その中に複数のスクロール可能な領域が生成することがあります。複数のスクロール可能な領域のうち、どれをターゲットとするかについては、各ブラウザともウインドウ内での疑似フォーカス位置を尊重するのではなく、マウスカーソルの位置を尊重してスクロール対象を決定しています(マウスドライバの多くが採用する動作とは対照的ですが、この方がより人気があるようです)。

ですが、コンテンツ内で例外的に別ウインドウを持つことのあるプラグインでは各ブラウザ、動作が異なっています。

Geckoは、コンテンツ内の存在に対しては、CSSによるスクロール可能領域なのか、プラグインなのかを区別していません。WM_MOUSEWHEELWM_MOUSEHWHEELをGeckoが受信すると、カーソル位置の下にあるウインドウを調べます。ここでプラグインのウインドウも含め、自分以外のウインドウで、自分と同じプロセスのウインドウが発見されると、それに対して受け取ったものと同内容のメッセージを送信します。受け取った側は、そのメッセージを自分たちで処理し、消費してしまった方が良い場合は、次のウインドウプロシージャを呼び出さない、という行動をとれます。自分たちに必要ないイベントなのであれば、次のウインドウプロシージャ(通常はその親ウインドウのもの)を呼ぶことになります。

つまり、Fx3.5.x以前と、Fx3.6.2以降でプラグイン上でスクロールできなくなる、というケースはプラグインがメッセージを自分たちで消費してしまったことを意味しています。このケースにおいて、もし強引にスクロールを行ってしまうと、本当にプラグインの中身がスクロールしたり、ホイールの回転にあわせてなんらかのリアクションが行われていた場合にはプラグインの快適な利用を妨害してしまうことになります。

ちなみに、Google Chromeの挙動はすこしテストしてみると明確です。WebKitのウインドウがメッセージを受け取った場合、プラグインのウインドウに対してはメッセージを再送信していません(WebKitのウインドウ間では行っているようです)。ですから、メッセージをプラグインが不必要に消費してしまう心配がありません。ですが、この方法にはもちろん問題点もあります。それは、そのプラグインがWM_MOUSEWHEELWM_MOUSEHWHEELを処理するものだったとしても、シームレスな操作ができないということです。

たとえば、Flash Playerのコンテンツがスクロールバーを持っていたとします。Geckoでは他のコンテンツ、textareaiframeと同様に、そのコンテンツの上にカーソルを移動させるだけでスクロールができます。Google Chromeではプラグインの場合にだけ、そこをクリックしてからホイールを回転させなくてはいけません。

大多数のユーザにとってコンテンツがプラグインであるか、そうではないかは分からない、もしくは関係のないことですので、Geckoはユーザにシームレスな操作体験を提供するように設計しているのです。

ところで、実際問題よく分からない問題がひとつあります。

youtubeのビデオでよく見かけるのですが、メッセージを消費してしまうものと、そうではないものがあります。Flashのコンテンツを生成したオーサリングツールの違いによるものなのか、はたまたFlashアプリケーションの作者が自由にコントロールできるものなのかはよく分かっていません。Flashではわざわざホイールイベントをリスニングしてまでハンドリングしないと消費することもできないと思うのですが、ホイールをもともと使わないFlashアプリがそんなコーディングをしているのも不自然なように思います。

Re: Firefox Flashプラグイン上でのホイールスクロール 初回投稿日時: 2010年03月23日17時57分56秒
カテゴリ: Google Chrome Mozilla Core
固定リンク: id=2010032301
リンク元: 0件
SNS: (list)

例が悪いかもしれないが, Google Chromeの場合ニコニコ動画のコメント欄は, Flashによるスクロール領域だが, Flashにフォーカスがある場合, マウスがFlashのスクロール領域上ではflashによるスクロール領域が, 動画上(Flashのスクロール領域外)およびページコンテンツ上ではページがそれぞれシームレスにスクロールできる。

Winspectorでメッセージを監視していても、Google Chrome上のFlash Playerがフォーカスを持たない場合、Flash PlayerのウインドウはWM_MOUSEWHEELメッセージを受け取っていません。ですが、指摘されている通り、フォーカスとは関係なく確かにスクロールは可能です。ソースコードを追い切れていませんが、Javascriptでニコニコ動画自身がDOMイベントを伝達させているのかもしれません。

さて, 大多数のユーザにとってどちらがユーザーフレンドな設計といえるでしょう。

こちらが議論の主題であるべきです。個別にこのケースだとスクロールできないけど、他のブラウザではスクロールできるのでバグなんだ、というのは乱暴すぎて話にならない、ということです。

2010年3月25日

Bug-org 353776 need the surrounding text support for some language input 初回投稿日時: 2010年03月25日10時53分07秒
最終更新日時: 2010年03月25日10時56分40秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010032500
リンク元: 1件
SNS: (list)

Theppitak Karoonboonyananさんがついに修正してくれました。今日のビルドから、Geckoはretrieve_surroundingシグナルと、delete_surroundingシグナルに対応しています(Linux)。

後者はタイ語等、一部の言語に必要ですが、日本語での使い道は思いつきません。ですが、前者は入力済みの内容をIMが取得できるということですので、変換精度を劇的に改善させることができると思います(IM/変換エンジン次第)。

ちなみに、retrieve_surroundingシグナルでは現在カーソルのある段落のテキストを返します。HTMLエディタで全文をやりとりすると大変なことになるためです。段落の定義は、カーソルの直前にある改行の直後からカーソル位置の直後にある改行の手前までです。

2010年3月28日

Bug-org 553975 Caret is painted under textframe in input/textarea element 初回投稿日時: 2010年03月28日14時21分01秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010032800
リンク元: 0件
SNS: (list)

LinuxでIMの色設定を使うように修正中に発見したバグです。

未確定文字列の背景色を指定しているとinput要素とtextarea要素ではキャレットが背景色よりも下側に描画されて表示されなくなるというバグです。input要素とtextarea要素の中身すらGeckoではDOMツリーを作って管理していますが、この内容の描画処理を単純化するためにpositionedなボックスとして扱っています。このため、CSSのレイヤー的には、inputtextareaの(本来の)コンテンツレイヤーの上層に、実際のコンテンツが描画されるpositionedのレイヤーが来るという形になっていました。しかし、キャレットを常にコンテンツのレイヤーに挿入するようにしていたため、positionedな実際のコンテンツがこれを上書きしてしまうというバグを生んでいました。

今回のパッチではキャレットもこのケースではpositionedなレイヤーに配置するように修正しています。