この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
LinuxでIMの色設定を使うように修正中に発見したバグ第二弾です。キャレットが(未確定文字列を含む)選択文字列内にあっても、常に黒、もしくはCSSのcolorの値を利用して描画してしまうというバグです。たとえば、通常の設定のままinput要素内で、未確定文字列の背景色を黒、文字色を白に設定しておくとキャレットは黒のまま、背景が黒の場所に描画されてしまい、見えません。この修正で、選択範囲では選択範囲の前景色を利用するように修正しています。
友人から指摘されたバグです。google.co.jpではIMEが未確定の状態でもサジェストで候補が表示されますが、MS-IME利用時にテキスト部分をクリックしてもキャレットが移動するだけで項目が選択されません。
原因はIMEのマウスハンドリングのリファクタリングにありました。新しいコードでは座標から該当する文字の位置を計算しますが、指定位置で発見したテキストフレームのテキストノードがエディタ内のものかどうかを確認していなかったため、未発見とせずに処理を続行し、(もちろんきちんとオフセット計算ができず)常にオフセットがゼロだと算出していました。
trunkでは修正終了、現在、1.9.2.4へのapprovalを申請中です。なお、google.co.jpをiframe等で読み込んだ場合には別のバグでまともに機能しないかもしれません。こちらもtrunkでは修正済みですが、具体的に問題になるメジャーなケースを発見していないのでbranchでの修正は行っていません。
こう、相変わらず芋づる式にバグが見つかって、本題が進まないです。
Bug-org 299603のためにまさかスタイルシートのバグまで対応しなくてはならなくなるとは思いませんでした(バグを直さないとreftestが現在のtrunkでも通ってしまう)。
1.9.2 branchでも修正しました。Fx3.6.4で修正されます。
万博記念公園の花見客の車列が、日曜日には中環に渋滞を引き起こしていましたが、さすがに平日はそうでもなく。
大量のコンテンツを含むtextareaやHTMLエディタをSelect Allで選択するとハングアップするというバグです。
根本的な原因はselection関係のコードのパフォーマンスにあるっぽいのですが、regressionの原因となった呼び出し側では、幸い、通常の選択範囲が変更されるときに問題のメソッドを呼ばなくて済むのでそのように修正しています。
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のスタイルを参照しなくてはいけません。
背景色を変更しているinput要素(type="text"もくしはtype="password")で文字を選択したときに、選択色の背景色と実際の背景色が似ていても選択色が反転されなかったというバグです。
Bug-org 472410の修正時にスタイル指定の情報を直接参照してしまっていて、実際のレンダリング結果と齟齬が出ている状態で反転機能を殺しているのが原因でした。このへん、コードのレビュアと必要とされる知識を持った人が食い違うのでこういうことは起こりやすいかもしれません。
LinuxのIMのコードのリファクタリングでcompositionイベントにあった古いコード用のnsTextEventReplyの利用者がゼロになったので、これとこれにXPレベルでアクセスするためのnsIPrivateCompositionEventインターフェースを削除しました。
もともとスタック上で利用されるクラスだったのでメモリ使用量への影響は皆無だと思いますが、エディタからhackyなコードの削除に成功しました。エディタはあまりメンテされていないのでまだこういう汚いコードがいくつかあるので、順次、本格的な対応でつぶしていきたいですね。
エディタ内でフラグが二重に管理されていて、同期できていなかった(というかしていなかった)バグです。
ns*Editorクラスは、実際の編集処理をns*EditRulesクラスに任せています。ns*EditRulesクラスは各ns*Editorクラスのインスタンスの初期化時に行われますが、ここでフラグの内容がコピーされていました。しかし、nsIEditor::SetFlags()が呼ばれてもns*EditorRulesへの反映処理は全くありませんでした。
今回の修正でフラグは全てnsEditorで保持するように一本化し、ns*EditRulesは逐一、nsEditorに問い合わせるように修正しています。
またこのバグでコードを整理中に!flags & kFlagXといったミスを発見しました。もちろんコメントでは!(flags & kFlagX)を意図していました。この手のミスはありがちですし、コーディングルールの桁数制限上、非常に見づらいので全てのフラグの問い合わせがメソッドでできるように修正しています。
OOPPで別プロセスのウインドウを生成するとその上ではマウスホイールでスクロールできないというバグです。
Geckoはカーソル下のウインドウでホイールイベントを生成していますが、このときにnsWindowのメソッドを直接呼び出します。このポインタは発見したウインドウにあらかじめプロパティとして保存しておいたものですが、プロセスをまたいで取得できてしまいます。このため、別のプロセスのnsWindowに対してアクセスしてしまうと、当然のことながらクラッシュします。このクラッシュを防ぐために、Geckoは発見したウインドウハンドルが別プロセスのものなら処理を中断していました。
というわけで、OOPPによって生成された別プロセスのウインドウ上でも、処理を全く行っていない、というのがこのバグの原因でした。対策として、別プロセスのウインドウだった場合、ウインドウのツリーを遡っていって、自分のプロセスのウインドウが出現した場合、そのウインドウに対してSendMessage()でメッセージをリダイレクトするようにしています。
LinuxでuimやiBus以外のIMを利用している場合、未確定文字列がある状態でクリックすると確定されなくてはいけませんが、これがBug-org 520732の修正で壊れていました。
諸事情から、ResetInputState()がIMに確定を指示した後、実際にIMから来るシグナルを無視し、Gecko内で保存していた未確定文字列を強制確定するようになっています。このシグナル無視は変換終了のシグナルが来るまで続きますが、このシグナルが来た時にGecko内で変換終了イベントを生成してしまっていました。このため、自前で確定する前にnsEditorで未確定文字列が残ったまま、IMEの変換中のモードが解除されてしまう、という状況に陥っていました。
ちなみに、未確定文字列をログに吐く時に文字化けしてしまっていたバグもついでに直しています。
Linuxで時々エディタにIME無しで文字を入力できなくなっていたバグです。これもBug-org 520732の修正によるregressionです。
nsIWidget::CancelIMEComposition()の処理に問題があり、変換中では無い場合にも処理を行い、これによってその後来るIMからのシグナルを無視する状態になっていました。現在、フォーカスを持ったエディタが再読み込み等で破棄されるときにのみ呼び出されます。そして、Linuxでは環境によってはIMオフでの入力でもIMEのシグナルでキー入力を通知されます。これら二つの条件に当てはまるとシグナルがひたすら無視され、文字が入力できない、という状態になっていました。
nsEditorEventListenerはnsIEditorとしてオーナーを記憶していましたが、これをnsEditorとすればキャストやQIを省略できてすっきりする、というバグです。
行数的には減らないんですが、コードの見た目はそれなりにすっきりしています。また、いちいちIDLを変更しなくてもメソッドを変更、追加できるのでこの方が開発しやすくなっています。
ime-mode: normal;でパスワードフィールドでIMEを使えるようにしていても、マウスのクリック等で未確定文字列を強制確定できない、というバグです。
元々はパスワードフィールドでもIMEが使えたはずなのに、nsIEditorIMESupport::forceCompositionEnd()でLinuxでのみ、パスワードフィールドならパフォーマンス向上のためにnsIWidget::ResetInputState()を呼ばない、という無用な最適化が入っていたのでこれを削除しています。
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要素の外でクリックした時にも問題があったので、同時に修正しています。
今回の修正でも修正されていない類似のバグはまだ数多く残っていますが、現在のサイクルでできる限り修正してしまいたいと考えています。
ヨドバシカメラで見てきましたが、思ってたよりは安定した映像でした。少なくとも、IMAXデジタルシアターで3Dのアバターを見たときにスクリーンの端に近づくほど映像が二重なままに見える、というようなことはありませんでした(まあ、たかだか50インチ程度だからということなんでしょうけど)。ただ、ゴーグルの位置が固定されていたので実用レベルでどうなのかは相変わらず不透明です。私は姿勢が悪いし首を傾ける癖があるので、どの程度まで斜めになっても立体的に見えるのかは気になってるんですが。まあ、普段は寝転がって見ることの方が多いのでなおさら3D化って個人的には恩恵ないんですけどね。