この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、
断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。
Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではない ことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。
順次、修正していく予定ですのでしばらくお待ちください。
もずはっく日記(2012年9月)
2012年9月7日
overflow-x
か、overflow-y
の一方がhidden
で、もう一方の方向にスクロール可能な要素で、マウスホイールを使ってhidden
な方向にもスクロールできてしまうことがあるというバグです。
Geckoはマウスホイールでのスクロール対象にはトランザクション の概念を持っていますので、現在のリリースビルドであっても、例えば、overflow-x: hidden;
な要素で、先にY軸方向にスクロールし、すぐにX軸方向へのスクロール操作をすると、スクロール対象がその要素に固定されたままになっているので、本来はX軸方向のホイールイベントでの、スクロール対象として算出されないはずのこの要素でスクロールを実行してしまいます。
さらに、D3E WheelEventが実装された ことにより、Macでは、一つのホイールイベントがX軸、Y軸両方向へスクロールすることがあります。
スクロール量を計算する際に、overflow
値を考慮して、hidden
なら単にスクロール量をゼロにするように修正してあります。
DLBI の一部投入より、このテストのランダムオレンジがトップ3に入ってしまったので、急遽修正が必要になりました。
ランダムオレンジの原因は、テストの開始にonload
イベントを利用していたため、レイアウトが完了する前にマウスイベントを発生させてしまって、望み通りの要素でマウスイベントが受け取れていないことでした。
Geckoでは、DOMキーイベントがエディタに届いた時に、ネイティブのショートカットキーに一致するキーかどうか、調べるのですが、その時に、DOMキーコードから、ネイティブキーコードに変換するメソッドにミスが見つかりました。
Fx15以降で: キーに、Linux側の設定で、なんらかのショートカットキーを割り振っている場合には問題があると思います。
Bug-org 775414の修正 によるregressionです。
command +tab でアプリを切り替えてキーを離すと、最初にcommand キーを押したウインドウに対して、NSFlagsChanged
イベントが送信されるのですが、この時に、例外が発生してしまっていました。
この時のNSFlagsChanged
イベントはいい加減で、keyCode
の値が、a キーと同じ、ゼロが入っています。NSFlagsChanged
はモディファイアキー以外のキーコードが入っていることを前提にしていませんでしたので、通常のキーイベント処理のパスが走り、NSFlagsChanged
イベントではアクセスできないプロパティにアクセスしてエラーとなっていたのです。
例外が発生しないようにするだけの修正をこのバグでは入れています。Mozilla17にも近日中に入ると思います。
抜本的な修正は、Bug-org 786956 で行う予定です。それまでは、Firefoxでcommand +tab を入力し、他のアプリに切り替えた際には、意味不明なa キーのkeyup
イベントが発生したままになります。
Bug-org 674477の修正 時に出てきた懸念です。overflow-x: hidden;
で、横スクロールが行われなかった場合、未使用のデルタ値の残量をwidgetに返す際に、どうしましょっていうバグです。
常に消費してしまうと、Macではジェスチャーに再利用されなくなり、スワイプによる、「戻る」や「進む」が使えなくなってしまいます。逆に、常に残してしまうと、意図せず、「戻る」や「進む」になる可能性があります。
これらの問題を回避するために、スクロールのターゲットの祖先に、その方向へスクロールできる要素があるかどうかを検査し、ある場合は、消費してしまい、無い場合は消費しないように修正しました。
これにより、スクロールしようとしただけなのに「戻る」や「進む」になってしまった、という状況にはならないようになったのではないかと思います。
D3E WheelEvent実装時に、テスト用の追加したユーティリティに、strict warningが出ることが分かったので、これを修正しました。これが、一連のホイールイベント関連の修正では、現在のところ、これが最後になる予定です。
2012年9月14日
Firefox Inputへの報告 からの修正第二弾です。独りよがりなコメントで意味が分からないものばっかりだったり、自分専用twitterだと誤解してるクレイジーな利用者が多いと評判ですが、今後も確認はしてますので、良質な バグ報告を待っています。
さて、バグの内容ですが、Firefoxでソースビューアに、外部エディタを指定した場合、そのエディタのパスに非ASCII文字が含まれていると、開くのに失敗し、内蔵してるソースビューアで表示されてしまうというものです。
原因は、nsIPrefBranch::GetCharPref()
で取得したパスを、nsIFile::InitWithPath()
のパラメータに渡していたことです。GetCharPref()
ではなく、GetComplexValue()
で、nsIFile
のインスタンスを直接取得するようにして修正しています。
TSFのログも、リリースビルドで取れるようになりました。詳しくは、modestの記事 を参照してください。
2012年9月18日
ITextStoreACP::InsertTextAtSelection()
には、パラメータのフラグによって、テキストを選択位置に挿入することで、選択がどのようになるのか調べるだけの機能があります。MSDNには、このメソッドに関しては、read、write、どちらのロックが必要なのかは明言していないのですが、Geckoは今まで、フラグの内容にかかわらず、read-writeロックが行われているか確認していました。しかし、TSFのログを詳細にとれるようにしてみると 、ATOKとの通信時に、ATOKは、readロックのみでアクセスしてきていることに気付きました。それによる実害は不明ですが、writeロックが必要な理由も特に無いので、クエリのみの場合はreadロックのみで動作するように修正しています。
nsTextStore::InsertTextAtSelection()
は、ITextStoreACP::InsertTextAtSelection()
の実装なのですが、nsTextStore::SetText()
から利用されてもいて、TIPから呼ばれたのか、内部で呼んだのか、ログでは見分けがつきにくかったり、そもそも、フラグの値によって、動作が大きく変わるメソッドなので、大きめの実装になってしまっているので、分割し、内部での呼び出しで、インターフェースメソッドは呼ばないように変更した方が良いという修正です。
サイドバー
日記内のナビゲーション
Twitter