もずはっく日記(2012年3月)

Bug-org 452393 Accelerators should not be affected by keyboard layout Part Deux. 初回投稿日時: 2012年03月17日11時17分56秒
カテゴリ: Mozilla Core Mozilla13 バグ修正
固定リンク: id=2012031700
SNS: Tweet (list)

長い間放置されていたLinuxのkey hellバグです。ヘブライ語のキーボードレイアウトは、そのままだとヘブライ語の文字か、ASCIIの記号を、Shiftを押しながらだとASCIIのアルファベットの大文字を入力できます。

QWERTYでQのキーだと、/が割り当てられているため、keypressイベントのcharCodeは、"/"の文字コードとなり、ASCII文字の入力キーなので、alternativeKeyCodesには何も入りません。このため、Ctrl+/としてしか機能せず、Ctrl+Qが使えませんでした。

今回の修正では、Shiftを押す、押さないでASCIIのアルファベットか、そうではないのか切り替わってしまうキーの場合、alternativeCharCodesに、そのユーザがインストールしているキーボードレイアウトのうち、ASCIIアルファベットが入力可能なレイアウトで入力されるアルファベットを付加するようになりました。

ちなみに、WindowsやMacではイベントモデルの違いからこの問題はありません。

Bug-org 672175 Clean up / reorganize / better encapsulate our scroll widget code and figure out some way to write tests for it 初回投稿日時: 2012年03月17日11時32分05秒
カテゴリ: modest Mozilla Core Mozilla13 バグ修正
固定リンク: id=2012031701
SNS: Tweet (list)

Windowsのマウスホイールのハンドリングコードは、歴史的な事情から様々な挙動のドライバが存在しているため、非常に複雑です。これをより細かく分割し、なおかつ自動テストも行えるように、ということで再整理、自動テストの作成を行うバグです。

現在、自動テストはまだレビューを受けている最中ですが、ほとんど動作を変えることなく、コードの整理自体は終わりました。今回の変更により、マウスホイールの挙動をログに記録することができるようになっています。

いくつか、挙動が変わっている点は以下のようなものがあります。

• いくつかのstaticな変数が動的に確保されるようになった
• mousewheel.enable_pixel_scrollingと、mousewheel.emulate_at_wm_scrollを変更した後にFirefoxを再起動しなくても反映されるようになった
• Elantechのタッチパッドで、「戻る」「進む」の操作をした際に、Alt+←や、Alt+→を生成していたが、Webアプリに妨害されないように、コマンドイベントで処理するように変更された

Bug-org 729774 Don't include composition string in the result of retrieve_surrounding signal 初回投稿日時: 2012年03月17日11時46分05秒
カテゴリ: Mozilla Core Mozilla13 バグ修正
固定リンク: id=2012031702
SNS: Tweet (list)

LinuxでもIMEはカーソル位置周辺のテキストを取得することができ、また、カーソル位置周辺のテキストを削除することもできます。これは再変換や、タイ語等の複雑な文字の入力に必要な機能なのですが、これらの動作時に未確定文字列が既に存在している場合、GTKのドキュメント通りに動いていないことを発見したので、それを修正しました。

retrieve_surroundingシグナルを受け取った場合、アプリは未確定文字列を含まない文字列を返さなくてはいけませんが、今回の修正では、未確定文字列を取り除くのはもちろん、未確定文字列入力時に削除された、選択されていた文字列も復元するようになりました。ただし、CompositionEvent等を利用して未確定文字列の発生時に選択位置を変更したりする奇妙なWebアプリとだと実際のエディタの内容と齟齬がでる可能性はありますが、そのような場合にはそもそも実用性が疑わしいので、今のところは問題無いレベルの実装になったと思います。

delete_surroundingシグナルを受け取った場合、アプリはretrieve_surroundingで返した文字列に対して処理を行わなくてはいけないので、あわせて修正しています。また、これの実装は指定された範囲を一旦選択し、削除コマンドをエディタに送る、というものですので、現状のnsEditorの実装からすると未確定文字列がある場合にはそもそもまともに動いていなかったと思われるので、一旦未確定文字列を取り消し、未確定文字列によって削除された文字列を復元してから、選択・削除を行い、また再び未確定文字列を復元する、という動作になりました。このため、CompositionEventが複数回発行されますが、この際に何らかの動作を行うWebアプリでは問題がある可能性がありますが、現在ではこれが限界です。

Bug-org 720659 "Auto-completing" address bar doesn't play nice with IME 初回投稿日時: 2012年03月17日11時54分27秒
カテゴリ: Firefox Mozilla Core Mozilla13 バグ修正
固定リンク: id=2012031703
SNS: Tweet (list)

少し前に、一時的に有効になっていた、URLバーでの自動補完ですが、IMEの確定時にはうまく動作しなかった、というバグです。

compositionendイベント時にエディタに対して文字列操作、選択範囲の操作を行っていたのですが、そのタイミングではエディタはまだイベントを受け取っていないため、IMEの未確定文字列がある状態の、制限のある動作しかできない状態だったのでうまく動かなかったようです。

compositionendイベント時にはnsAutoCompleteControllerのIMEの状態管理のみを行うようにし、その直後に必ず発生するinputイベントで、nsEditorが完全にIMEの処理を終了してから処理を行うように修正しました。

このバグがURLの自動補完を行う機能の最後のblockerだったので、これが修正された直後にBug-org 735187も修正され、Firefox 13では今度こそデフォルトで有効になる予定です。

IMEでの挙動をblockerに指定してくれたことを感謝せずにはいられませんね。

Bug-org 728103 Shouldn't we change modifier for HTML accesskey from Control to Control + Option? 初回投稿日時: 2012年03月17日12時07分20秒
カテゴリ: Firefox Google Chrome HTML Mozilla Core Mozilla14 Safari バグ修正
固定リンク: id=2012031704
SNS: Tweet (list)

MacのHTMLで指定されたアクセスキーを利用するための、モディファイアキー、SafariやGoogle ChromeにあわせてControl+Optionにした方がよくね?っていうバグです。Mozilla 14の初期段階である今、様子を見るために投入されました。

修正前はControlキーだけでアクセスキーを利用できていたのですが、MacではControlキーと、何か一文字の組み合わせは、かなりの数、EmacsライクなOSネイティブのエディタの操作のためのショートカットキーになっています。これとバッティングすると、HTMLのアクセスキーが勝ってしまっていたのでEmacsライクなショートカットキーを多用するユーザにはページ毎に挙動が変わる可能性があるという不愉快なことこの上ない感じのバグがありました。

今回の修正ではパッチを見れば分かるように、contentのアクセスキー設定のみを変更しています。chromeのアクセスキー設定は変更していませんので、拡張のXUL UIの中では今までと挙動が変わっていません。これについて、問題がやはりあるんだ、という場合にはバグを報告してください。対応を検討します。

それ以外のプラットフォームでは引き続き変更の予定はありません。Geckoのアクセスキーはそれなりに議論を積み重ねた後に現在の形に落ち着いていますので、それを変更するにはMacのように実害を提示しなくてはいけません。それでもやはりWebKitにあわせる方が良い、という場合、変更することによるデメリットよりもメリットが上回ることをきちんと説明し、自分でパッチを提出してください。ご覧の通り誰でも書けるパッチですので(自動テストも若干修正が要りますが、やはり同レベル)、クレーマーとしてbugzillaに来るのは勘弁してくださいね。

Firefox Inputからいくつかピックアップ #2 初回投稿日時: 2012年03月28日10時04分06秒
最終更新日時: 2012年03月28日12時05分39秒
カテゴリ: Firefox Mozilla Core 雑談
固定リンク: id=2012032800
SNS: Tweet (list)

技術的に可能かは分かりませんが、変更予定箇所をあらかじめ、Test pilotなどを通してアドオンなどの形でユーザーに使ってもらい、フィードバックを得るようにすればいいと思います。例えば、今回のアップデートではスムーズスクロール機能の動作が変わりましたが、事前にユーザーから評価してもらうほうが、よりユーザーフレンドリーだと思います。

新機能に問題があると考えるのであれば、bugzillaで直接苦情を出しましょう。明らかなバグに関しては日本語のフォーラムに書けば誰かがエスカレーションできますが、意見の分かれることに関しては直接英語でやりとりするしかありません。誰も他人とまったく同意見で主張を展開できるわけではありませんから。

矢印ｷｰのｽｸﾛｰﾙの量が多くなって微調整が効かなくなった｡ Chrome(Cr)と同じ様な大雑把で速いｽｸﾛｰﾙに切り替えたのだろうけど､大移動ｽｸﾛｰﾙはｽﾍﾟｰｽｷｰによるﾍﾟｰｼﾞｽｸﾛｰﾙもあるし､以前の小幅で細やかなｽｸﾛｰﾙがきめ細かくてよかった｡ ｽｸﾛｰﾙ量を指定できる様にｵﾌﾟｼｮﾝ→詳細→一般→ﾌﾞﾗｳｽﾞに設定項目を設けて欲しい｡

Firefox 13以降では、toolkit.scrollbox.verticalScrollDistanceで変更可能になっています。

コンテンツデータ破損エラー このページは、データの伝送中にエラーが検出されたため表示できません。 このページは、データの伝送中にエラーが検出されたため表示できません。Web サイトの所有者に連絡を取り、この問題を報告してください。

私も詳しいことは分かりませんが、セキュリティバグをつぶしたことで出てきた問題のようです。Webサイトが空のLocationレスポンスヘッダを返してきていることが原因です。解説を見た限りでは、空の値というのはナンセンスなようですし、対応させるとセキュリティ上の懸念があるとコメントしている開発者も居るので、Webサイトの運営者に対して連絡してください。

prefs.jsは暗号化されないのでしょうか。 エクステンションによっては重要な情報もほぞんされるとおもうのです。

prefs.jsはGeckoの設定保存機能で、これをアドオンからも利用できるだけです。アドオンが暗号化して保存すべき情報があるのであればそれはアドオン自身で他の保存方法を用いるなり、暗号化した値をprefs.jsに保存すべきです。ただし、アドオンはバイナリコンポーネントを含まない限り、簡単にソースコードを取り出せるので、復号化可能な暗号であれば気休めにしか済みません。本当にそのあたりに気を払うのであればそういった情報は保存しないようにしましょう。

フレーム内がスクロール出来ない

報告されてるページ

body要素でoverflow-y: hidden;が指定されているからです。Webページを書かれた人の指示通りですので、それが問題であれば管理されている方に連絡してください。overflow: hidden;は英語の通り、溢れた部分を隠してしまう指定であって、スクロールバーのみを隠す指定ではありません(仕様)。

Bug-org 622245 Implement DOM3 textinput event 初回投稿日時: 2012年03月28日12時39分58秒
カテゴリ: Google Chrome IE Mozilla Core バグ却下
固定リンク: id=2012032801
SNS: Tweet (list)

D3Eではtextinputというイベントが定義されていましたが、HTML5のinputイベントの劣化版でしかなく、同じ働きのイベントを発生させる意味が無いので仕様書から削除されました。

これを受けて、Geckoではこのイベントは実装しないことにしました。そもそもIEとWebKitではイベント名も発生タイミングも動作も異なっているので互換性のために実装する、といった理由もありません。

Bug-org 672175 Clean up / reorganize / better encapsulate our scroll widget code and figure out some way to write tests for it #2 初回投稿日時: 2012年03月28日12時43分33秒
カテゴリ: Mozilla Core Mozilla13 Mozilla14 バグ修正
固定リンク: id=2012032802
SNS: Tweet (list)

自動テストも含め、全てのパッチが入りました。

実際のコードの修正はMozilla 13、自動テストの追加と、それ用のAPIの実装はMozilla 14になっています。

Bug-org 668606 oninput (input event) doesn’t work for contenteditable elements 初回投稿日時: 2012年03月28日12時50分46秒
カテゴリ: Javascript Mozilla Core Mozilla14 バグ修正
固定リンク: id=2012032803
SNS: Tweet (list)

W3Cでcontenteditableや、designModeのようなHTMLエディタでもinputイベントを生成することでコンセンサスが得られたので早速Geckoの挙動も修正しました。

designModeエディタの場合はイベントターゲットは常にルート要素、つまりhtml要素になります。

contenteditableエディタの場合は、editing host、つまり、ルート要素か、編集できない要素を親に持つ要素になります。つまり、contenteditable属性を持つ要素がネストされていた場合、一番外側の要素をターゲットとしてイベントが発生します。

Bug-org 722961 Make some tests for autocomplete with IME 初回投稿日時: 2012年03月31日13時25分25秒
カテゴリ: Firefox Mozilla Core Mozilla14 バグ修正
固定リンク: id=2012033100
SNS: Tweet (list)

IME利用時のオートコンプリートの自動テストが今までなかったので作れるパターンのものは一通り作りました。これで、今後、オートコンプリートに変更があってもある程度のレベルでIMEの挙動が壊れることはないとおもいます。

Bug-org 703774 Intermittent ERROR TEST-UNEXPECTED-FAIL | content/chrome/layout/xul/test/test_bug159346.xul | scrollbar didn't change curpos by mousemove after cursor is back on the scrollbar button #3 初回投稿日時: 2012年03月31日13時30分05秒
最終更新日時: 2012年04月03日12時11分09秒
カテゴリ: Mozilla Core Mozilla13 Mozilla14 バグ修正
固定リンク: id=2012033101
SNS: Tweet (list)

自動テストのランダムオレンジの修正です。

スクロールバーのボタンを押しっぱなしにした時の自動リピートのテストなのですが、scrollbar要素からgetAttribute()でスクロール位置を取得した際に、値をNumberに変換していなかったため、"11" > "9"のような状態に陥ると比較に失敗していました。凡ミスです。

Bug-org 739557 intermittent editor/libeditor/html/tests/test_dom_input_event_on_htmleditor.html | Editor4, html and div has contenteditable attribute: wrong element was edited - got , expected a 初回投稿日時: 2012年03月31日13時42分28秒
カテゴリ: Mozilla Core Mozilla14 バグ修正
固定リンク: id=2012033102
SNS: Tweet (list)

もうひとつ、ランダムオレンジの修正です。

ランダムな理由についてはまだ理解できていないのですが、原因はElement.focus()メソッドの挙動の誤解にありました。contenteditableな要素がネストしていて、子孫側の要素にキャレットをおいて入力した時に、イベントのターゲットが正しく祖先側の要素になっているかをテストする前に、そのiframe要素内のwindowにフォーカスをあて、その後、子孫側の要素のfocus()を呼んでいました。しかし、これでは要素にはフォーカスが移動しないことをコードを読んで確認しました。このため、window.focus()だけで上手い具合にキャレット位置がテスト開始前に運良く移動してくれた場合(ほとんどのケースですが)にのみテストがパスしていたようです。何故非同期になる時とならない時があるのかが分かっていませんが。