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

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

もずはっく日記(2016年2月)

2016年2月6日

Windows用Firefox 64bit版がいよいよ「本当の」正式リリースに近づいてきたか? 初回投稿日時: 2016年02月06日12時12分59秒
最終更新日時: 2016年02月06日12時28分58秒
カテゴリ: Firefox Flash IME Mozilla47 plugin Windows バグ修正
固定リンク: id=2016020600
リンク元: 8件
SNS: (list)

……なんてタイトル付けると、「いやいや、Windows用Firefoxの64版も前から正式リリースされてんじゃねーか」とツッコミ入れられることが多いんですが、元々、Windows用64bit版はテクニカルプレビュー扱いでのリリースで、こっそりと各国語版の Firefox をダウンロードでのみ行われるという話でした。

64bit版を正式リリースにすると聞いた時には既にNightlyでプラグインプロセスを強すぎるサンドボックスで保護していたため、IMEが全く使えないことが分かっていました。このままリリースすると問題が大きすぎるから製品イメージの低下が深刻だぞと指摘してみたんですが、以下、実際の下り。

Masayuki Nakano [:masayuki] (Mozilla Japan) 2015-09-04 09:24:08 PDT

(In reply to Benjamin Smedberg [:bsmedberg] from comment #1)

> Regression from sandboxing. We're not going to block Fx64 release on this.

If sandboxing is enabled in default settings, it sounds bad because Japanese major video site, Nico Nico Doga can post comment from Flash Player's input field (and the comment is scrolled over the movie). Therefore, cannot use IME on x64 build makes our product image for them too bad since the regression causes that they cannot use one of main purposes to use web browser.

Benjamin Smedberg [:bsmedberg] 2015-09-04 09:29:36 PDT

This is for Firefox 64-bit, which is still a tech preview and will not go to anyone by default. We're not willing to ship it without a Flash sandbox.

Masayuki Nakano [:masayuki] (Mozilla Japan) 2015-09-04 09:36:45 PDT

(In reply to Benjamin Smedberg [:bsmedberg] from comment #3)

> This is for Firefox 64-bit, which is still a tech preview and will not go to
> anyone by default. We're not willing to ship it without a Flash sandbox.

Did you mean that Firefox x64 for Windows won't be released as official release? I.e., users will need to one or more steps for downloading the x64 version than x86 version? E.g., they need to click a link like "Other languages" in the current download page? (Or hidden, like ESR) If so, it sounds not bad.

Benjamin Smedberg [:bsmedberg] 2015-09-04 09:49:24 PDT

Yes, it will only be available from the "all systems and languages" link.

という感じでした。ところが、ふたを開けてみると、MozillaのFuture Releasesというブログが取り上げたので誤解されたのか、「正式リリース」として大々的に各種ニュースサイトでデメリットの説明抜きに多くの記事が書かれました。その結果、多くのユーザさんが、完全に普通のリリースと思って気軽に使い始めたようで、案の定、このFlashでIMEが使えない問題や、その他、インストールパスの問題等々の初歩的な問題で苦情を書かれているのを多々見かける形になっていました。

しかし、ここに来て、Firefox 47では多くの問題が解決されてきています。特に日本人にとって大きいのが、FlashとIMEの問題。これについては、えむけいさんが、How about forcing windowless mode on Win64 Fx? We only support Flash anyway.と提案されていたのですが、当時は問題が大きすぎて現実的な案に思えませんでした。しかし、Mozillaのエンジニアリングのお偉いさん達が、Adobeと協力して問題解決にあたることを決断し、windowedモードと同様の動作を実現するべく様々なチームを巻き込んでwindowlessモードの大がかりな改善が始まりました。

日本からの大きな貢献は、windowlessモードでも未確定文字列をFlash Playerがインラインで扱えるように修正したBug-org 1208944です。誠さんががんばってくださって、Flash Playerが利用しているIMM APIのうち、重要なものをhookし、Gecko側でそのAPIの呼び出しに応対するというものです。私には無理な高度な修正をやっていただけて無茶苦茶助かりました。

しかもこの修正、Geckoで私が各国語のIMEの色んなバグに対応し、ハックを行った後に生成されたプラットフォーム非依存な情報からhookしたAPIに返す値を再計算しているので、そのハックの恩恵の全てをFlash Player上で受けられるようになっています。Adobeにリストアップしてもらった利用中のIMM APIの一覧からすると、例えば、ANSI APIにしか対応していない一部のIMEはFlash Player上ではクラッシュしているものと思われますが、その部分もUnicode API経由で期待通りの値を返すようになったので、修正されていることになります。

他にもwindowlessモードの描画パフォーマンスの改善が行われているようです(この辺、関連バグも含めてよく分からない)。

そしてついに、Bug-org 1201904の修正が入り、Windows用Firefox 64bit版ではサンドボックスをデフォルト設定のまま有効にしていると、全てのFlash Playerが、この改善された今までとは違うクオリティのwindowlessモードで動作するようになったところです。

IMEに関してはまだまだ問題が出てくる可能性があるとの事なので、64bit版Nightlyでニコニコ動画等を利用されている方は、是非、見つけた問題を報告してください。プロダクトのクオリティの良さの大半はテスタさんからのバグ報告にかかっていますのでよろしくお願いします。

2016年2月7日

regression (後退バグ)の報告は早ければ早いほどよい 初回投稿日時: 2016年02月07日00時05分26秒
最終更新日時: 2016年02月07日00時23分17秒
カテゴリ: Firefox Mozilla Core
固定リンク: id=2016020700
リンク元: 0件
SNS: (list)

先日、いつものようにNightlyを更新してみると、見ているページをTwitter等のSNSでシェアするための"Share this page"ボタンをクリックしても、SNSを選択するポップアップが開かないregressionが発生していることに気付きました。

普段から、高頻度で利用している機能だったので、かなり不便でしたから、Browser Consoleでボタンをクリックする度に出てくるJavascriptのエラーと共に、即、regression報告しました(Bug-org 1244647 - "Share this page" button doesn't open its popup due to ReferenceError: DOMParser is not defined in microformat-shiv.js)。

報告から8時間後に担当者の目にとまり、それから2時間半でパッチが提出され、レビューに入りました。そして、報告から36時間半後にツリーに修正パッチが入り、mozilla-centralに半日後にマージされ、修正に至っています。

報告から2日ほどでパッチがmozilla-centralまで行き、そこから遅くても24時間ぐらいで修正済みのNightlyビルドがリリースされますので、なかなかのスピードでした(報告したのが日本時間での一般的な活動時間ではなく、担当者のタイムゾーンの活動時間に報告していたらさらに短い時間で解決していたでしょう)。

開発者からすると、なんらかの修正を入れた直後にそのregression報告が来ると、担当は他の仕事に移りきる前にregression対応ができますし、何よりも、変更した内容に対する記憶が鮮明ですので、心当たりがある状態で調査するのは非常に効率が良いのです。

そういう訳で、regressionはできる限り早く報告すると、素早く対応してもらえる可能性があり、そもそも、対応してもらえる可能性が高いということを覚えておいてもらえたらと思います。

(もっとこまめに見つけたバグの原因のあたりをつけるよりも前に報告しないといけないなと思いつつ、できていないので、自戒を込めて……)

Bug-org 1250050 Add a pref to control whether wheel events should be sent to plug-ins 初回投稿日時: 2016年10月15日20時16分02秒
カテゴリ: Firefox Flash Mozilla46 plugin Windows バグ修正
固定リンク: id=2016020701
リンク元: 1件
SNS: (list)

さて、徐々に日記の更新を再開していきたいと思います。やはり、私のやってる範囲は地味な変更が多いので他の方に知っておいてもらった方が良いですし。

このバグはWindows版でwindowlessモードで動作しているプラグイン(主にFlash Playerですが)にマウスホイールのメッセージをデフォルトアクションとして送信するようになったことに関連しています。

現在のところ、Flash Playerが実際にマウスホイールメッセージを処理するかを取得、もしくは結果を受けとる方法が存在していないため、Geckoはメッセージをプラグインに送信した後、そのメッセージを処理されたものとして、Gecko内でスクロール処理を行わないようにしています。これは、ホイールを操作することによって、プラグイン内とGeckoと両方でなんらかの処理が行われてしまうのを防ぐためです。

しかし、これによって、windowlessプラグインによってマウスホイールによるスクロールが阻害されてしまうという不満が出てきます。特に、windowlessプラグインは滅多にスクロール等でマウスホイールイベントを処理していないという点が問題になります。

そこで、プラグイン上でのホイール操作を諦め、常にGeckoに処理を行わせるようにする設定を追加しました。about:configからplugin.mousewheel.enabledfalseに設定することでこのバグを回避できます。

なお、この設定は、Firefoxの再起動を必要としませんので、特定のプラグインコンテンツでホイールが必要な時のみ、上記の設定を一時的にtrueに戻すといった使い方が可能です。