もずはっく日記(2014年10月)
2014年10月30日
Bug-org 1083629 Composition in a designMode editor is canceled when you click the editor on Linux
初回投稿日時: 2014年10月30日22時23分48秒
カテゴリ: GTK Mozilla Core Mozilla35 Mozilla36 バグ修正
SNS:
Tweet (list)
designModeのエディタで、未確定文字列を入力中に、<body>要素の外側、つまり、<html>要素の部分をクリックすると、GTK版でIMEがiBusの場合、未確定文字列が確定されず、キャンセルされてしまう、というバグです。Bug-org 1065835の修正によるregressionです。
Bug-org 1065835の修正では、未確定文字列の確定のリクエストがあった場合、IMEの挙動に関わらず、直前の未確定文字列をそのまま確定するように修正しました。これに伴い、もし、XPレベルで確定のリクエストを出さなかった場合、各widgetがIMEに確定のリクエストを出した場合は、そのIMEの挙動に依存するようになっています。最近のiBusに関しては、gtk_im_context_reset()を呼び出した場合、非同期で未確定文字列をキャンセルするという挙動になっていますので、このようなバグが発生しました。
具体的に、どこでキャンセル処理が発生していたのかは確認していませんが、<html>要素をクリックした場合、<body>要素内でクリックしたのとは違って、XPレベルでの確定リクエストが発生していないことに問題があります。そこで、nsHTMLEditorEventListener::MouseDown()を調査してみると、contenteditableで生成されたHTMLエディタのために、ハンドリングすべきmousedownイベントかどうかを、イベントのターゲットが、エディタのルート要素かその子孫であるかどうかを確認していました。ここで問題なのが、エディタのルート要素の定義です。nsHTMLEditorでは、ルート要素は、contenteditable属性で生成されている場合は、その、editing hostになりますが、designModeを"on"に設定して生成された場合は、<body>要素になります。このため、<html>要素をクリックした場合は、エディタ外でのmousedownイベントであると判定される結果になってしまっていました。
今回の修正では、Auroraでの修正も必要だったので、ルート要素の定義は変更せず、単純に、mousedownイベントを処理すべきかどうかの判断を、nsEditor::IsAcceptableInputEvent()で確認するようにしました。このメソッドは、もともと、この用途での利用を想定したものなので、期待通りに判断できますし、実績もあります。
これにより、designModeで生成されたHTMLエディタでは、どこでmousedownイベントが発生しても、強制確定のリクエストがXPレベルで発生するようになりました。