もずはっく日記

Firefox3.6でマウスホイールを使ったときに、上方向にはマウスドライバの加速が効くけど、下方向へのスクロール時は通常のスピードに制限されてしまう、というバグです。

例のシステム設定のスクロールスピードの上書きによるregressionです。二つのイージーミスがありました。

1. 負のデルタ値の計算時に正の値で計算した加速の限界速度とをそのまま比較していた
2. イベントのデルタ値が算出した限界速度よりも速い場合にも、限界速度に丸め込んでしまっていた

これだけ書くとコードを書いてる時のテストで見つからなかったのが変な感じもしますが意外とこれにハマる環境は少ないはずです。

nsIEditorIMESupport::endComposition()は昔のなんでもかんでもXPCOMで作ろう、としていた当時のエディタ内部用のメソッドなのに、scriptableになっていました。外部から未確定文字列の編集を終了させたい場合はforceCompositionEnd()を使ってください。

そろそろ他の作業が落ち着いてきたのでTSFの作業を再開しようと考えています。

今のところ、最大の癌であるNatural Inputの動作にあわせて修正していくのではなく、まずはW3C側のHTML、DOMの仕様と、TSFの柔軟すぎる仕様の両方に合わせるためにnsEditor、nsIMEStateManager、nsTextStoreそれぞれの修正、および関係の改善、そして新しいnsLockedContents (widget/src/xpwidgets ?) を作成しなくてはいけないと思います。

nsLockedContentsはロックが要求された時に生成され、ロックが終了する時にそれまでに行われた変更をまとめて通知するというのが基本的な機能です。これにより、Webコンテンツは従来通りいつでもDOMに対して変更をかけられますが、TSFがロック中はTIPからこのクラス内にキャッシュした内容にしかアクセスできないため、ロックが実現されているように振る舞うことができるのではないかと考えています。また、キャッシュしてしまうことにより、ロック中に多数のドキュメントへのアクセスが集中しても高速に処理することが可能になります。問題は、writeロックがかけられている状態で、実際にJavascriptがDOMツリーを変更してしまった場合、ロックが解除されるまで座標の問い合わせには対応できなくなる点です。この点に関してだけは仕方ないかなと考えています。