この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2017年10月)

2017年10月20日

Bug-org 143038 Horizontal Scrolling with Mouse wheel+ modifier key 初回投稿日時: 2017年10月26日03時09分54秒
カテゴリ: Firefox Mozilla Core Mozilla58 WheelEvent バグ修正
固定リンク: id=2017102000
SNS: (list)

実に16年前に報告されたバグですが、修正しました。

安いマウスだと今でもホイールは縦スクロールしかサポートしていませんし、また、少し古いノートPCのタッチパッドでも、縦スクロールしかサポートしていませんでした。この様なデバイスを使っている時でも、Shiftキーを押すことで横スクロールして欲しいというバグでした。

かなり前から巻き込まれていたのですが、今まで修正しなかったのは、WheelEventdeltaYdeltaXに回すべきか否かという問題が大きかったのと、既にXULアドオンでこれを実現するものが存在したからです。

WheelEvent.deltaYをゼロにして、WheelEvent.deltaXWheelEvent.deltaYの元の値をセットする方が個人的にはメリットがあると思いました。というのも、Webアプリによっては、自前でwheelイベントを捕まえて、スクロール処理を行っている場合があります。この様なケースでも、ユーザは当然、Shiftキーを押していれば横スクロールを期待すると思います。

ですが、これをやってしまうと、Shiftキーを押した状態で、WheelEvent.deltaYの値を使うようなゲーム等があった場合に、そのようなイベントは絶対に発生しないことになります。これは非常によくありません。Firefoxのシェアが下がっている今、このような、他のブラウザでのみテストされた場合に動かなくなるような修正はできません。

しかし、Google Chromeは、WheelEvent.deltaXの値がゼロのまま、デフォルトアクションが単純に横スクロールになるという実装を行っていました。そこで、これに倣えば、現在のシェアを考えると、問題無く動作する(上記のようなWebアプリでは横スクロールできませんが)ということになりますし、前述のXULアドオンが57以降では使えなくなるということで、急遽、修正することにしました。

というわけで、Shiftキーを押しながら、縦スクロールの操作をホイールで行うと、Firefoxでも横スクロールするようになります。ただし、これはデフォルトアクションがそのように変わっただけで、発火されるWheelEventの内容に変化はありません。つまり、WheelEvent.deltaYが非ゼロで、WheelEvent.deltaXがゼロ、WheelEvent.shiftKeytrueのイベントのデフォルトアクションが横スクロールになります

また、これまでは、IEと動作をあわせるために、Shiftキーが押されている場合にはそのタブの履歴を辿るようになっていましたが、これは、これまでのmacOS版と同じAltキーに変更になりました。この設定は、mousewheel.default.actionmousewheel.with_alt.action等でカスタマイズ可能です。詳しくはソースコードにあるコメントを参照してください

Web開発者のみなさんに注意していただきたいのは、macOS版でShiftキーを押しながら、このようなレガシーなマウスを利用した場合の動作についてです。macOSは、Shiftキーを押しながら、マウスホイールを縦に回すと、横スクロールのイベントがOSレベルで発火します。このため、macOS版Firefoxでは、 今回実装した機能は、デフォルト設定では無効化されています。しかし、macOS自身の機能により、横スクロールになります。そして困ったことに、WheelEvent.deltaYはゼロです。つまり、macOS版とそれ以外のFirefoxでは、Shiftキーを押している時の、縦方向へのホイール操作によって発火するイベントが異なります

この注意点はまさに、私が、WheelEvent.deltaXの値を書き換えるべきではと思っていた理由のひとつではあるので、非常に気になるポイントです。

2017年10月26日

Bug-org 1409155 ATOK 2006, ATOK 2008, ATOK 2009 and ATOK 2010 crash 64-bit version of Firefox on Win 8.1 or later and ATOK 2007 doesn't work fine with same environment 初回投稿日時: 2016年09月24日20時57分57秒
最終更新日時: 2017年11月02日01時56分56秒
カテゴリ: Firefox IME Mozilla Core Mozilla56 バグ検証中
固定リンク: id=2017102600
SNS: (list)

Firefox 56.0.1では、Win7以上かつ、メモリが4GB以上ある環境では、自動で64bit版にアップデートされましたが、その場合に、ATOK 2010以前を利用されているユーザからクラッシュリポートが多々報告されているようです。

手元でVMで検証してみたところ、Windows 7を利用しているユーザの場合、32bit版のFirefoxでも、64bit版のFirefoxでも、特に(既知のものは除いて)新たな問題は無さそうに思えます。

一方、Windows 8.1では、64bit版のFirefoxを利用している場合、ATOK 2006は変換中にクラッシュ、ATOK 2007は候補ウインドウやサジェストウインドウが適切に表示されない(ブランクだったり、サイズがおかしかったり)、ATOK 2008とATOK 2009はオンにするだけでクラッシュ、ATOK 2010はWindows 7以降だとそもそも新規インストールできないので検証出来ていませんが、クラッシュリポートを見る限りはWin 8.1以降では不安定なようです。

そこで現在のところ、ATOK 2010以前、つまり、TSFTIPになる前の、IMMのIMEは64bit版のFirefoxがWindows 8以降で動作している場合には無効化してしまおうとしています(32bit版のFirefoxと、Windows 7では何も変わりません)。

何か意見がありましたら、連絡お願いします。

なお、ATOK内部でのクラッシュで、Google Chromeやメモ帳など、他の64bitアプリで同様の症状が見られますので、Mozilla側でやれることは何も無いと、現在のところは思われます。

スムーズに承認され、Firefox 57へもupliftされました。つまり、Firefox 57以降では、Win8以上の環境で、x64版Firefoxを利用している場合、ATOK 2006、ATOK 2007、ATOK 2008、ATOK 2009、ATOK 2010は利用できません。

Windows側の実装の変化により、Win8以降で、これらのバージョンのATOKは、そもそも、x64版のアプリ上でまともに使えないので、ATOK 2017かそれ以降にアップグレードすることをお勧めします。

一アプリ開発者としては、ATOK 2010からでも、既に8年近く経過している今、そろそろ買い換えても良い頃合いじゃないかと思います。地味にバグ修正や、変換効率の改善が積み重なっているわけですし。毎月ちょっとずつなら出せるし、Androidのデバイスも使ってるっていう人であれば、ATOK Passportとかあるわけですしね。

Bug-org 1390562 regression: enter key doesn't insert newline in gmail compose window if "editor.use_div_for_default_newlines" is false 初回投稿日時: 2017年10月26日03時24分31秒
カテゴリ: Editor Mozilla Core Mozilla58 バグ修正
固定リンク: id=2017102602
SNS: (list)

Bug-org 1297414の修正により、GeckoのHTMLEditorのデフォルトの改行処理が、<div>要素や<p>要素を用いたものに変更可能になりましたが、これをデフォルト設定にするといくつかのサイトが壊れるということで、今まで通りに<br>要素をデフォルトとするようにBug-org 1357482で、リリース版と後期ベータ版では動作を戻していました。このバグは、元の動作である、リリース版と後期ベータ版でのみ発生するバグです。

Bug-org 1357482でデフォルトの設定を互換モードに戻したものの、このモードの一部の挙動がBug-org 1297414の修正で変わっていたことが原因でした。

これにより、GmailでHTMLメールを作成する際に、一行目を入力、二行目を空のままにして、三行目を入力、そして、一行目の末尾に戻って、Enterキーを押しても、改行が(見た目では)挿入されないという動作になっていました。

詳しい修正内容はこのバグのパッチを見てもらえば分かりますが、理にかなった修正とは言えません。しかし、標準仕様の草案にも今のところ存在しない、Geckoの古い動作に戻して、現存するWebアプリとの互換性をとるにはこれしかありませんでした。