2012年10月20日
twitter.comの、ツイートを書き込む<textarea>に、overflow: hidden;が指定されているため、CSS仕様を忠実に守っているFirefoxでのみ、キャレットを移動してもスクロールできず、入力した内容が確認できないことがある、というバグです。
modestに記事を書きましたが、CSS仕様では、overflow: hidden;の要素では、スクロールできるユーザインターフェースを提供してはならない、となっています。勘違いしてる人を時々見かけますが、ユーザインターフェースというのは、GUIのことだけではなく、操作全般を指します。キー入力や、マウスホイール、スワイプ等でもスクロールできてはいけません。
実際、他のブラウザでも、中身が編集可能ではない要素で、overflow: hidden;を指定していると、一切、スクロールできませんが、何故か、<textarea>の場合や、contenteditableな場合にはキャレットの移動によって、スクロール可能でした。
今回の修正で、エディタの内容が変更された場合と、キャレットが移動した場合に、編集可能な要素だと、スクロールが行えるように修正しています。編集不能な要素では引き続き、ユーザによるスクロールは不可能です。
gfxのヘッダファイルのせいで、warningが大量に出力されていたバグです。
このwarningが出ていたのは、VCのみのようなんですが、そのwarningが、floatを戻り値とするメソッドで、1.0、もしくは-1.0を返していたのがコンパイラの機嫌を損ねていたようです。
レビュアのコメントにもありますが、こういう、ロスが発生しない場合にこのwarningを出すのは、どうなんでしょうね? 仕様があるのか無いのか知りませんが。
ことえりで、かな打ち設定にしていた場合、IMEが使えない局面、つまり、エディタがフォーカスを持っていない場合でも、keypressイベントの、charCodeに、IMEがオフの場合に入力される文字ではなく、かな文字がセットされている、というバグです。
他のプラットフォームの挙動にあわせるため、IMEがキーボードレイアウトをオーバーライドしていても、そのキーボードレイアウトがASCII capableではない場合、その時点で割り当てられている、ASCII capableなキーボードレイアウトを利用して、charCode値を算出するように変更しています。
これで、何がうれしいかと言うと、charCodeを利用して、独自のショートカットキーを実装したWebアプリでも、ことえりのかな打ちユーザや、中国語の多くのIMEのユーザ、ハングルIMEのユーザが、そのショートカットキーを利用できるようになったわけです。
ちなみに、ATOKはキーボードレイアウトをオーバーライドしていませんでしたので、かな打ちでも、元々この問題は発生していませんでした。
Cocoaの、NSFlagsChangedイベントのハンドラをまるごと書き直して、まともなものにしよう、というバグです。
これまでは、前回のイベント時との、モディファイアフラグの差分から、その差分に応じて、イベントから通知されたkeyCodeを利用して、キーイベントを生成するという、不思議なコードになっていました。ですので、keyCodeが0の場合には、aキーのイベントが発生してしまったり、フラグの差分から、複数のイベントを同じキーのイベントとして発生させていたり、モディファイアフラグが変わらないモディファイアキーのイベント、例えば、左のshiftキーを押しながら、右のshiftキーを押した時にはイベントが発生しない、といった問題がありました。
今回の修正で、基本的にはkeyCodeを基に、単にキーイベントを生成するようになりました。通常、普通にキーを押した、離した、といった場合にはこれだけで完璧に動きます。
ややこしいのが、keyCode値が0のケースです。この場合、shift、option、command、controlのフラグの変化は分かるのですが、これだけだと、実際に変化したキーが、左右どちらのものか分かりません。そこで、ドキュメント化されていない、デバイス依存のモディファイアフラグを用いて、ややハッキーな形で修正を行っています。デバイス依存といっても、物理キーボードの種類によって変わる、というほどデリケートなものではないことは確認しているので、通常のキー押下時に、キーコードと、モディファイアフラグの関連づけを行い、それ以降に発生した、keyCodeが0のNSFlagsChangedイベントハンドリング時に利用する形をとっていますので、かなり安全だとは思います。ちなみに、このイベントが発生するパターンとして、command (+ shift) + tabというパターンのみ、確認しています。
ひょっとすると、似たようなイベントを生成してくる、アクセシビリティ改善用の外部アプリがあると、うまく動かないかもしれませんが、このハンドラで動かないレベルだと他のアプリでも動くかどうかかなり怪しいので、無いんじゃないかと思います。もし、問題がありましたら、bugzillaに報告してもらえれれば対応していきます。
ちなみに、修正時にWebKitの動作も見ながら作業してましたが、それよりも期待通りに動くようになってしまってます。
当初、Mozilla 19での修正でしたが、問題が見つかったため、Mozilla 20に持ち越されました。詳細は、Bug-org 815383の修正の記事を参照してください。
これまで、Geckoでは、ネイティブのIMEのイベントから、DOMイベントを生成して、その時点でフォーカスのある要素に対して、そのイベントを発行していました。しかし、これでは、意図せず、強制確定前にフォーカスが移動してしまったケースでは、おかしなことになってしまいます。また、現在のXPレベルのコードでは、エディタ以外に未確定文字列を編集中であるかどうかを管理しているクラスがありませんでしたので、色々と不便がありました。
そこで、compositionstartで、インスタンスを作成し、compositionendまでの一連のIME系のイベントを全て、compositionstartを発行したイベントで発行し、compositionend後に破棄されるクラスを作ると色々と便利だよね、というアイデアになったわけです。
TextCompositionというクラスのインスタンスが、ひとつの、未確定文字列編集を表していて、これのプロセス全体でのリストが、nsIMEStateManagerで管理されている、という形をとっています。
この修正によって改善したのは、
- ワンセットになる、IME関連イベントが全て、同じ要素で確実に発生するようになった
- 生成された
TextCompositionが自動テストで生成されたものかどうか判別できるので、強制確定を含めた自動テストが書けるようになった
の2点のみです。
IMEの強制確定が行われる直前にフォーカスが移動してしまい、強制確定に失敗して、エディタの動作がおかしくなるバグの、実例です。
このバグでは、<iframe>でdesignModeのエディタを二つ用意して、片一方で未確定文字列がある場合に、もう一方をクリックすると、最初の方には未確定文字列が残り、新しい方にcompositionendイベント等が発行されていました。
同じドキュメント内でのフォーカス移動だと、ひとつのPresShellに全イベントが集中するので、大丈夫なのですが、このように、複数のドキュメントをまたぐと、それぞれのPresShellがフォーカスを得た時にイベント受け取り、そのドキュメント内のアクティブ要素に対してイベントを発行するため、このようなことが発生していました。
現在は、Bug-org 705057の修正により、TextCompositionがPresShell非依存でイベントの発行先を管理するようになっているので、問題なくなっています。
2012年10月22日
Logicool(あちらではLogitech)のマウスドライバ、SetPoint 6.50の動作について
初回投稿日時: 2012年10月22日15時30分39秒
最終更新日時: 2012年10月25日16時44分56秒
カテゴリ: Mozilla Core
固定リンク: id=2012102200
SNS:
(list)
Logicoolのマウスドライバ・ユーティリティである、SetPoint 6.50がリリースされています。自動アップデートではまだ配布されていないのか、SetPoint 6.32のUIからはアップデートできませんでしたが、サイトから直接ダウンロードして入れることはできました。
SetPoint 6.32までは、Geckoの生成したウインドウに対しては、高解像度スクロールを行うために、適切なメッセージを送信してきていました。標準通り、スクロール量を3行に設定しておくと、だいたい、1/3行分ごとにホイールのメッセージが送信されていました。
これに対して、SetPoint 6.50では、FirefoxにLogitech SetPoint 6.5、というアドオンをインストールしようとするようになりました。どうも、高解像度スクロールをGeckoで利用するには、このアドオンが必須のようで、このアドオンを入れていない状態では、常に3行ごとのホイールイベントを送信してきて、高解像度スクロールが行われなくなりました。たとえば、このアドオンが提供されていないThunderbirdでは高解像度スクロールが行えなくなりました。
そして、Firefoxにこのアドオンを入れた場合も問題なのですが、なんと、デルタ値を1単位で大量のホイールイベントを送信してくるように修正されています(デフォルトの、3行スクロール、という設定は、デルタ値120で3行分という意味)。しかも、手元のマウスで確認したところ、文章を読んでいるときに、ゆっくりと回す感じで、1ノッチ分だけホイールを回してみたところ、SetPointが指定してるスクロール量が従来の1/3になっていることが分かりました。このため、非常にスクロールスピードが遅くなっていると感じられると思います。
このため、とことん細かいスムーズスクロールが可能にはなっていますが、Gecko側のスムーズスクロール等とは相性が悪い感じがありますので、SetPointをアップデートされる場合にはご注意下さい。
当初、Thunderbirdや、SeaMonkey、そのほかのXULRunnerアプリでは6.50にアップグレードすると、高解像度スクロールが無効になると書いていましたが、米Logitechの開発者の方の指摘から、再検証したところ、6.32でもFirefox以外のGeckoベースのアプリでは高解像度スクロールがサポートされていませんでした。ここに訂正しておきます。
スクロールスピードの問題に関しては、引き続き、検証してもらっています。
Firefox上で、Flash Playerが遅い、ハングアップする、日本語入力できない、という方には、保護モードの解除をお勧めします
初回投稿日時: 2012年10月22日20時43分07秒
最終更新日時: 2015年05月27日11時03分38秒
カテゴリ: Firefox Flash Memo plugin Windows
固定リンク: id=2012102201
SNS:
(list)
Firefox 36以降では、簡単に変更できるようになっていますので、その解説記事を参照してください。
つまり、この記事の複雑な手順での作業は必要なくなっています。
注意: Flash Player 10.3のサポートは終了しましたので、ダウングレードによるトラブル回避は非常に危険です。絶対に、行わないでください。
5月以降、Firefoxに関する苦情を各所で目にすると、半数以上がFlash Playerに絡んでいるもの、という印象があります。Windows Vista以降のFirefoxでFlash Playerの動作が遅い、ハングアップする、といった方や、Flash Playerの提供している入力欄で、Google日本語入力が使えない、かな打ちがIME問わず出来ない、といった方には、保護モードの解除をお勧めします。と言いますか、日本語入力の問題に関してはこれしか解決策はありません。
- パフォーマンスが異様に悪い
- クラッシュする
- ブルースクリーンが出る
- 他のアプリにまで影響が出る
- 保護モードの解除では解決しなかった
といった症状の方はグラフィックチップ(GPU)のドライバのバグが原因の可能性が高いので、ドライバの更新を試された方が良いです。
保護モードの解除の仕方は簡単です(Adobeのサイトにも手順がありますが、以下のやり方が分かりやすいでしょう)。
- [スタートボタン]をクリックし、[アクセサリ]にある、[メモ帳]を右クリックします。
- コンテキストメニューの、[管理者として実行...]をクリックします(通常設定ならこのあと、UACの確認ダイアログが出ます)。
- そのメモ帳で、Windowsが32ビット版の場合、
C:\Windows\System32\Macromed\Flash\mms.cfgを、64ビット版場合、C:\Windows\SysWOW64\Macromed\Flash\mms.cfgを開きます(スクリーンショットは64ビット版)。
- そのファイルの最後に、
ProtectedMode=0という行を追加します。
- ファイルをそのまま上書き保存し、Windowsを再起動します。
これにより、他のWebブラウザで動作している時と同様に、問題の原因となっている保護モードが動いていない状態でFlash Playerが動作するようになります。
ここで、セキュリティを気にする方であれば、Flash Playerの保護モードを切るということに不安を感じられるかもしれません。
確かに、この設定変更を行うと、Flash Playerのセキュリティは弱くなってしまうのは事実です。しかし、保護モードは、セキュリティホールを突かれ、万が一攻撃がPC内に及んだ時に、その影響範囲を最小限に抑えるための、最後の防壁です。ですので、常にセキュリティホールが修正されている最新版を利用し続ける限りはある程度は安全と言えます。
また、そもそもこの機能は、Flash Player 10.3以前には実装されていませんでしたし、最新版であっても、他のブラウザ上で動作している時は動作していません。また、Windows XP上で動作している時にはブラウザを問わず機能しません。ですので、この状態を特に危険と考える必要はありません。
安全であることは大切ですが、誰もがセキュリティのためにインターネットへの接続をやめないのと同様に、機能が使えなくなるレベルのセキュリティであればユーザにとっては不要なものとしか言えませんので、ここのバランスは各利用者の方に判断してもらえれれば良いレベルではないかと思います。