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

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

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

2010年4月2日

Bug-org 554822 Caret should refer the actual text color instead of the value of CSS color property 初回投稿日時: 2010年04月02日12時31分38秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010040200
リンク元: 0件
SNS: (list)

LinuxでIMの色設定を使うように修正中に発見したバグ第二弾です。キャレットが(未確定文字列を含む)選択文字列内にあっても、常に黒、もしくはCSSのcolorの値を利用して描画してしまうというバグです。たとえば、通常の設定のままinput要素内で、未確定文字列の背景色を黒、文字色を白に設定しておくとキャレットは黒のまま、背景が黒の場所に描画されてしまい、見えません。この修正で、選択範囲では選択範囲の前景色を利用するように修正しています。

Bug 6738 MS-IME利用時に、google.co.jpのサジェストをクリックで選択できない 初回投稿日時: 2010年04月02日14時05分18秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010040201
リンク元: 0件
SNS: (list)

友人から指摘されたバグです。google.co.jpではIMEが未確定の状態でもサジェストで候補が表示されますが、MS-IME利用時にテキスト部分をクリックしてもキャレットが移動するだけで項目が選択されません。

原因はIMEのマウスハンドリングのリファクタリングにありました。新しいコードでは座標から該当する文字の位置を計算しますが、指定位置で発見したテキストフレームのテキストノードがエディタ内のものかどうかを確認していなかったため、未発見とせずに処理を続行し、(もちろんきちんとオフセット計算ができず)常にオフセットがゼロだと算出していました。

trunkでは修正終了、現在、1.9.2.4へのapprovalを申請中です。なお、google.co.jpをiframe等で読み込んだ場合には別のバグでまともに機能しないかもしれません。こちらもtrunkでは修正済みですが、具体的に問題になるメジャーなケースを発見していないのでbranchでの修正は行っていません。

芋づる 初回投稿日時: 2010年04月02日20時07分37秒
カテゴリ: 雑談
固定リンク: id=2010040202
リンク元: 0件
SNS: (list)

こう、相変わらず芋づる式にバグが見つかって、本題が進まないです。

Bug-org 299603のためにまさかスタイルシートのバグまで対応しなくてはならなくなるとは思いませんでした(バグを直さないとreftestが現在のtrunkでも通ってしまう)。

2010年4月6日

万博記念公園 初回投稿日時: 2010年04月06日19時15分51秒
カテゴリ: 旅行
固定リンク: id=2010040601
リンク元: 0件
SNS: (list)

万博記念公園の花見客の車列が、日曜日には中環に渋滞を引き起こしていましたが、さすがに平日はそうでもなく。

桜と太陽の塔の写真

桜に囲まれた広場の写真

桜並木の写真

桜の花のアップの写真

Bug-org 552493 Hang on select-all in large textbox (which repeats if I unfocus & focus Firefox) 初回投稿日時: 2010年04月06日20時01分08秒
最終更新日時: 2010年04月06日20時01分19秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010040602
リンク元: 0件
SNS: (list)

大量のコンテンツを含むtextareaやHTMLエディタをSelect Allで選択するとハングアップするというバグです。

根本的な原因はselection関係のコードのパフォーマンスにあるっぽいのですが、regressionの原因となった呼び出し側では、幸い、通常の選択範囲が変更されるときに問題のメソッドを呼ばなくて済むのでそのように修正しています。

2010年4月7日

Bug-org 183646 ::-moz-selection does not work in form controls (input[type=text], input[type=password], textarea) 初回投稿日時: 2010年04月07日12時59分10秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010040700
リンク元: 0件
SNS: (list)

input要素やtextarea要素では::-moz-selectionが適用されないというバグです。

Geckoはこれらの要素ではnative anonymousな要素を生成します。具体的には以下のようなDOMツリーが形成されます。

<input>(もしくは<textarea>)
  +- <div>
       +- text node
       +- <br>
       +- ...

これをもとにフレームを作ると

nsTextControlFrame
  +- nsBlockFrame
       +- nsTextFrame
       +- nsBRFrame
       +- ...

となっています。

::-moz-selectionは特殊で、nsTextFrameが選択されたテキストを描画する段階で直接、そのフレームのノードの::-moz-selection疑似要素のスタイルを参照しにいきます。このため、常にnative anonymousなdiv要素のスタイルを参照しに行って、スタイルが取得できていない、というのがその原因でした。もちろん、実際にはnsTextControlFrameのスタイルを参照しなくてはいけません。

2010年4月12日

Bug-org 556694 Selection color isn't reverted when input field is specified only background-color 初回投稿日時: 2010年04月12日14時38分01秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010041200
リンク元: 0件
SNS: (list)

背景色を変更しているinput要素(type="text"もくしはtype="password")で文字を選択したときに、選択色の背景色と実際の背景色が似ていても選択色が反転されなかったというバグです。

Bug-org 472410の修正時にスタイル指定の情報を直接参照してしまっていて、実際のレンダリング結果と齟齬が出ている状態で反転機能を殺しているのが原因でした。このへん、コードのレビュアと必要とされる知識を持った人が食い違うのでこういうことは起こりやすいかもしれません。

Bug-org 543398 Drop nsTextEventReply and nsIPrivateCompositionEvent 初回投稿日時: 2010年04月12日14時43分52秒
最終更新日時: 2010年04月12日20時00分24秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010041201
リンク元: 0件
SNS: (list)

LinuxのIMのコードのリファクタリングでcompositionイベントにあった古いコード用のnsTextEventReplyの利用者がゼロになったので、これとこれにXPレベルでアクセスするためのnsIPrivateCompositionEventインターフェースを削除しました。

もともとスタック上で利用されるクラスだったのでメモリ使用量への影響は皆無だと思いますが、エディタからhackyなコードの削除に成功しました。エディタはあまりメンテされていないのでまだこういう汚いコードがいくつかあるので、順次、本格的な対応でつぶしていきたいですね。

Bug-org 552914 nsEditor::mFlags is never modified by SetFlags() 初回投稿日時: 2010年04月12日14時52分37秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010041202
リンク元: 0件
SNS: (list)

エディタ内でフラグが二重に管理されていて、同期できていなかった(というかしていなかった)バグです。

ns*Editorクラスは、実際の編集処理をns*EditRulesクラスに任せています。ns*EditRulesクラスは各ns*Editorクラスのインスタンスの初期化時に行われますが、ここでフラグの内容がコピーされていました。しかし、nsIEditor::SetFlags()が呼ばれてもns*EditorRulesへの反映処理は全くありませんでした。

今回の修正でフラグは全てnsEditorで保持するように一本化し、ns*EditRulesは逐一、nsEditorに問い合わせるように修正しています。

またこのバグでコードを整理中に!flags & kFlagXといったミスを発見しました。もちろんコメントでは!(flags & kFlagX)を意図していました。この手のミスはありがちですし、コーディングルールの桁数制限上、非常に見づらいので全てのフラグの問い合わせがメソッドでできるように修正しています。

Bug-org 552163 [OOPP]Can not start scroll page by mouse wheel when mouse cursor is over a flash video. 初回投稿日時: 2010年04月12日19時11分22秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010041203
リンク元: 0件
SNS: (list)

OOPPで別プロセスのウインドウを生成するとその上ではマウスホイールでスクロールできないというバグです。

Geckoはカーソル下のウインドウでホイールイベントを生成していますが、このときにnsWindowのメソッドを直接呼び出します。このポインタは発見したウインドウにあらかじめプロパティとして保存しておいたものですが、プロセスをまたいで取得できてしまいます。このため、別のプロセスのnsWindowに対してアクセスしてしまうと、当然のことながらクラッシュします。このクラッシュを防ぐために、Geckoは発見したウインドウハンドルが別プロセスのものなら処理を中断していました。

というわけで、OOPPによって生成された別プロセスのウインドウ上でも、処理を全く行っていない、というのがこのバグの原因でした。対策として、別プロセスのウインドウだった場合、ウインドウのツリーを遡っていって、自分のプロセスのウインドウが出現した場合、そのウインドウに対してSendMessage()でメッセージをリダイレクトするようにしています。

2010年4月17日

Bug-org 558978 Looks like composition isn't committed after I clicked 初回投稿日時: 2010年04月17日13時23分13秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010041700
リンク元: 0件
SNS: (list)

LinuxでuimやiBus以外のIMを利用している場合、未確定文字列がある状態でクリックすると確定されなくてはいけませんが、これがBug-org 520732の修正で壊れていました。

諸事情から、ResetInputState()がIMに確定を指示した後、実際にIMから来るシグナルを無視し、Gecko内で保存していた未確定文字列を強制確定するようになっています。このシグナル無視は変換終了のシグナルが来るまで続きますが、このシグナルが来た時にGecko内で変換終了イベントを生成してしまっていました。このため、自前で確定する前にnsEditorで未確定文字列が残ったまま、IMEの変換中のモードが解除されてしまう、という状況に陥っていました。

ちなみに、未確定文字列をログに吐く時に文字化けしてしまっていたバグもついでに直しています。

Bug-org 558690 Textarea input fails unless one clicks elsewhere (addressbar, searchbar, forms, etc) first. 初回投稿日時: 2010年04月17日13時44分48秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010041701
リンク元: 0件
SNS: (list)

Linuxで時々エディタにIME無しで文字を入力できなくなっていたバグです。これもBug-org 520732の修正によるregressionです。

nsIWidget::CancelIMEComposition()の処理に問題があり、変換中では無い場合にも処理を行い、これによってその後来るIMからのシグナルを無視する状態になっていました。現在、フォーカスを持ったエディタが再読み込み等で破棄されるときにのみ呼び出されます。そして、Linuxでは環境によってはIMオフでの入力でもIMEのシグナルでキー入力を通知されます。これら二つの条件に当てはまるとシグナルがひたすら無視され、文字が入力できない、という状態になっていました。

2010年4月20日

Bug-org 558970 nsEditorEventListener should store its owner as nsEditor rather than nsIEditor 初回投稿日時: 2010年04月20日09時32分37秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010042000
リンク元: 0件
SNS: (list)

nsEditorEventListenernsIEditorとしてオーナーを記憶していましたが、これをnsEditorとすればキャストやQIを省略できてすっきりする、というバグです。

行数的には減らないんですが、コードの見た目はそれなりにすっきりしています。また、いちいちIDLを変更しなくてもメソッドを変更、追加できるのでこの方が開発しやすくなっています。

Bug-org 559754 IME Composition in password field cannot be committed by click (and forceCompositionEnd()) 初回投稿日時: 2010年04月20日09時36分09秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010042001
リンク元: 0件
SNS: (list)

ime-mode: normal;でパスワードフィールドでIMEを使えるようにしていても、マウスのクリック等で未確定文字列を強制確定できない、というバグです。

元々はパスワードフィールドでもIMEが使えたはずなのに、nsIEditorIMESupport::forceCompositionEnd()でLinuxでのみ、パスワードフィールドならパフォーマンス向上のためにnsIWidget::ResetInputState()を呼ばない、という無用な最適化が入っていたのでこれを削除しています。

2010年4月22日

Bug-org 544277 IME became unusable when switching focus on Gmail RTF Editor 初回投稿日時: 2010年04月22日13時13分00秒
最終更新日時: 2010年04月22日13時21分18秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010042200
リンク元: 2件
SNS: (list)

GmailのリッチテキストエディタにTabでフォーカスを移動するとIMEが無効になったままになるというバグです。

HTMLエディタのフォーカス処理がぐちゃぐちゃだったことが原因でした。非常に多くのバグがコード上では連携していたので一気に修正しています。

まず、Gmailのメール作成画面ではdesignModeを利用していますが、このdesignModeはドキュメントを特殊なモードに変更してしまうというもので、一部の例外を除き、designMode上の要素ノードはフォーカスをセットされません。ドキュメントノード自体がフォーカスを得るのみ、という特殊な仕様になっています。

nsFocusManagerはフォーカス移動時にnsIMEStateManager (ISM)にこれを通知し、ISMが新しいフォーカスに基づいてIMEの状態を設定します。ですが、designModeの特殊な事情によりフォーカス移動時にfocusイベントが発生しないため、ISM的には最後のblurイベント以降、何もフォーカスを持っていない状態が継続されていた、という状況になっていました。

つまり、ISMに常に通知を送るだけで修正できそうですが、この辺のコードは非常に複雑でこれだけを修正すると他でregressionが出ました。この前段階の処理にも問題があったということです。

少し話をHTMLエディタから離れて、フォーカスの仕様について考えてみましょう。nsFocusManagerの内部処理ではひとつ例外的に、本来はフォーカスを得られないものの、内部処理ではフォーカスを得る要素が存在します。それはドキュメントのルート要素です。ルート要素がフォーカスを得られないとTabによって選択するフレームを変更し、キーボードでスクロールする、ということができなくなってしまいます。ただし、本当にフォーカス可能な要素という訳ではないので、focusイベントやblurイベントは生成しません。この条件判定時に、nsFocusManagerはルート要素であるかどうかだけをチェックしていました。

そう、nsFocusManagerはルート要素はフォーカス可能で編集可能であることはない、という前提のもとに実装されてしまっていたのです。そこでfocusイベントを編集不能かdesignModeにより編集可能なルート要素には送らない、という本来の形に変更しました。これにより、ISMは正しく機能し、フォーカス処理にも問題はなくなりました。ですが、類似サイトをいくつか検証しているとまだうまくいかないケースがありました。それは<html><body contenteditable="true"></body></html>というケースです。

親からTabによりフォーカスを移動して来た時に編集不能なルート要素(html要素)が最初にフォーカスを受け取ってしまいます。ですが、ユーザから見たらbody要素にフォーカスが移動しているべきです。もちろんもう一度Tabを押すとbody要素にフォーカスが移動するのですが、スクロールバーが無いときには意味が分かりませんし、もともとtextarea要素と同じでそのような操作ができることをユーザは求めていません。そこで、このケースにおいてはTabによるフォーカス移動ではルート要素を無視するように修正しています。

これでおおむね動作するようになりましたが、Shift+Tabが根本的に動作していなかったことや、body要素の外でクリックした時にも問題があったので、同時に修正しています。

今回の修正でも修正されていない類似のバグはまだ数多く残っていますが、現在のサイクルでできる限り修正してしまいたいと考えています。

3D VIERA VT2シリーズ 初回投稿日時: 2010年04月22日22時51分53秒
最終更新日時: 2010年04月22日22時57分13秒
カテゴリ: 雑談
固定リンク: id=2010042201
リンク元: 0件
SNS: (list)

ヨドバシカメラで見てきましたが、思ってたよりは安定した映像でした。少なくとも、IMAXデジタルシアターで3Dのアバターを見たときにスクリーンの端に近づくほど映像が二重なままに見える、というようなことはありませんでした(まあ、たかだか50インチ程度だからということなんでしょうけど)。ただ、ゴーグルの位置が固定されていたので実用レベルでどうなのかは相変わらず不透明です。私は姿勢が悪いし首を傾ける癖があるので、どの程度まで斜めになっても立体的に見えるのかは気になってるんですが。まあ、普段は寝転がって見ることの方が多いのでなおさら3D化って個人的には恩恵ないんですけどね。