この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
ちょっと古いネタですが、Google Readerのサポートが終了、ということで、Firefoxのデスクトップ版でのGoogle Readerのサポートは、現在のリリース版である、Firefox 22以降で廃止されています。
Google Readerは既にサービスを終了していますが、Firefox for Androidでは、まだ、このサポートを削除していません(Firefox 22現在)。
気付いたら、以前から気になっていたバグが修正されていました。Firefoxでは、contenteditableでHTMLエディタを作成すると、常に、スペルチェッカが動いていましたが、spellcheck="false"で無効化できるようになったようです。
いくつかテストケースを書いて確認したところ、contenteditable属性がtrueの、editing host以外の要素がspellcheck="false"であっても良いようです。また、spellcheck="false"な要素内で、spellcheck="true"の要素を作成すると、その内部でのみ、スペルチェッカーが機能するようです。
ちょっと暇なので、たまにはニュース記事について言及してみる。ちなみに、元記事のマークアップがアホすぎるので、そのままソースレベルで引用したため、スタイルは変になってます。
1. iPhone や Android フォンユーザーが、Firefox OS フォンに乗り換えるとは考えられない
Firefox OS がスマートフォン市場に大きなインパクトを与えるには、Apple の iPhone や Samsung の GALAXY ユーザーが、Firefox OS フォンに乗り換えたいと思う何かが必要だ。だが、Firefox OS 自体、Android OS や iOS ほどパワフルなものではなく、Firefox OS 搭載デバイスのスペックも、既存のスマートフォンには敵わない。iPhone や Android フォンユーザーが、Firefox OS フォンに乗り換えたいとは思わないだろう。
OSとして『パワフル』という意味が分からないので、これはおいとくとして、スペックは、スマートフォンのメーカーが決めることであって、別に、ローエンドなモデルでしか動かない訳じゃないです。
Androidでは動かないような低スペックモデルでも動作する、というところが一番大切で、ケータイに何万円も出したくないユーザにも訴求することができますし、ハイエンド機でAndroidよりもスムーズに動作する、というあたりに強みがある訳ですね。
例えば、シングルコアCPUで、メインメモリが512MB未満の機種にAndroid 4.xを搭載し、モバイル向けブラウザとしては唯一といっていい、機能削減のないフルブラウザである、Firefox for Androidがまともに動作するかというと、そんなことはありません。これがFirefox OSだと、"そこそこ"動きます。日本のスマホユーザーにとって、"さくさく"という感覚はさすがにありませんが、少なくとも十分に実用レベルで動作します。
こういった点を踏まえると、個人的には今後の日本のフィーチャーフォンのOSとして非常に有利なんじゃないかと思ってます。もちろん、現在はそのようなことを想定して開発していませんので、ベンダさんとか、キャリアさんの貢献が必要となりますが。
また、さらに要求の厳しい組み込みOSとしても、可能性はゼロではないですよね。少なくとも、スペック要求が高い、Androidや、他社にライセンスする予定が無いであろう、iOSよりは有望です。
スマホOSとしては、後発であるという点と、まだJavascriptでしかコード書けないあたりに、不得手なジャンルがあって、問題を抱えていることは確かなので、別に楽観視はしていません。
3. Firefox OS 搭載スマートフォンは、ハードウェアスペックが低く、デザインが悪い
ZTE Open と Alcatel One Touch Fire には、iPhone 5 に勝るものは何もない。スペックは時代遅れだし、デザインも良いとは言えない。ハイエンドの GALAXY や iPhone はもちろん、人気の低い Android OS フォンと比較することさえ困難だ。
Moziila がハイエンドの製品に対応するまでは、消費者の関心を集めることは難しいだろう。
デザインに関しては主観でしか無いので、そもそも記事としてどうなんだというのと、なんでまた、1と同じことを書いてるんだって感じですが……
それはさておき、上述のように、ハイエンド製品に非対応なんていう事実は全くありません。
5. Firefox OS でしかできない特別な何かが必要だ
Samsung も Apple も、他社にはない独自機能をスマートフォンに搭載し、自分たちの製品を特別なものにしている。だが、Firefox OS デバイスには、"顧客を魅了する特別な機能"は、何も搭載されていない。
「iOS にも Android OS にもできないが、Firefox OS でならできる」
Firefox OS には、そのような何かが必要だ。
突然、Samsungの名前が出てきて、『あれ? OSの話じゃなかったの?』って感じですが、ベンダレベルで特別な機能が実装できないとか、そういうことはありませんので、完全に的外れです。
今存在しないことを批判されているのであれば、その通りですが、文面からはそういう感じではなさそうな印象を受けました。
6. Web ベース OS には死角がある？
「Web の利用はますます増加しており、そのニーズに応えるには、Web ベースの OS を提供するべきだ」
Mozilla の Firefox OS は、このような考えから生まれた。
だが Mozilla は、Web への常時接続が、世界中どこでも利用できるわけではないという事実を忘れている。常時接続が困難な国では、その国に向けた、その国の言語による Web サービス自体、数が限られている可能性がある。特に Firefox OS がターゲットとしている新興市場では、Web ベース OS はこの問題に悩まされるかもしれない。
ちょっと何を言ってるのかこれも分からないんですが、ひょっとすると、オンラインでなければHTML5アプリケーションは動作しないと誤解されているのでしょうか?
Mozillaの言う、Webアプリってサーバサイドで動くものを指しているのではありません。HTML5関連仕様では、様々な、オフラインに関する仕様があります。サーバにあるデータを処理するようなもの、例えばIMAPのメーラであっても、ローカルにキャッシュしちゃえば、見ることできますよね? そういう風にイメージしてもらうと分かりやすいかと思います。
エンドユーザに対して、この辺の宣伝が足りていないことは実感していますが、記事を書かれる方がこのレベルというのには正直、失望しました。
7. Firefox OS アプリが不足している
Mozilla は、Firefox OS アプリのプロモーションで良い仕事をしており、Firefox Marketplace には、すでに有力なゲームや、Facebook、Twitter などの必須アプリが揃っている。
だが、Apple の iTunes App Store や Google Play と比較すると、アプリ不足は否めない。これは Firefox OS にとっての大きな問題であり、先行する iOS や Android OS と競合していくには、Mozilla は早急にこの問題に対応しなければならないだろう。
各種ストアアプリは、上位の利用率が全体の大半を占めているので、ある意味で数は問題ではないのですが、まあ、印象悪いのは問題ですね。ただ、今までスマホが高価で利用できなかった地域で売れていけば、自然とアプリは増えていくんじゃないですかね。この点に関しては個人的には楽観視してます。
問題は、日本市場だと、Skypeや、LINEといった、『無いと話にならないアプリ』で、なおかつ、『HTML5アプリとして制作することが困難なもの』をどうするか、というあたりが深刻ですね。これらのアプリは、同等機能のものがあっても、ユーザには無意味で、『周りが使っているものが入っていないと駄目』の世界ですからね。
9. よりオープンであることは、より良いことなのか？
Mozilla は顧客に対して、Firefox OS が Android OS よりもオープンであることを謳い文句にして、売り込みをかけている。Android OS のコードは Firefox OS とは異なり、完全に無料ではないと主張しているのだ。
たしかにそうだし、その事実はスマートフォンベンダーや開発者にはアピールするかもしれない。だが、一般消費者にとっては、どうでもよいことだ。
私が不勉強なのかもしれませんが、たぶん、エンドユーザに対して、『オープン』を売りにはしていないと思います。ミッションを説く上で、言葉が出ている可能性は高いですが、売り文句にはしていないと思います。
現在のWebKitとBlinkに一極集中したモバイルのWeb環境が好ましくないのは、昔を知らないWeb開発者を除けば、誰の目にも明らかです。多様性のない世界は、停滞し、腐った牛乳しか産みません。これは、たとえ、Geckoが市場を独占したとしても同じことが言えます。
10. Mozilla には、他のモバイル OS を倒そうとする気概がない
Mozilla は、Android OS や iOS と競合する気はないと述べている。そうではなく、Android OS や iOS を望まない顧客に対して、代替 OS を提供したいのだという。だが、このメンタリティは間違っている。
Android OS は、Firefox OS のシェア拡大を阻むライバルとなるはずだ。Android OS は先進国だけでなく、新興市場の顧客からも人気が高い。Android OS はまた、顧客からだけでなく、スマートフォンメーカーからも高い人気を得ている。Mozilla が市場シェアを取りたいと思うのであれば、Android OS のシェアを削る覚悟を持つ必要があるだろう。
なんか極端な意見ですね。無理矢理にでもユーザに移行してもらいたい、という欲求をもつ企業、団体ではないということを念頭に置くべきです。自然と移行してくれるユーザを閉め出したりするわけでもありません。
特にAndroidに言えると思いますが、他に選択肢がないので、Androidを使っている層も一定数居るでしょう。かつてのデスクトップでのIE独占時代と同様です。そういった人達全てがFirefox OSを採るとは思えませんが、一定数、移行する人は居るかもしれません。選択肢の提供が目的であり、市場シェアナンバーワンになるといった、一般的な企業の目標とは根本的なところで異なっているのです。
このような考え方が必ず『失敗』に結びつくのであれば、デスクトップ版のFirefoxはシェアはもっと0%に近いはずです。
メトロ版Firefox (Metrofox)では、DOMキーイベントが、デスクトップ版とは違って、適切なイベントを発行できていない、というバグです。
Metrofoxでは、MetroInputクラスで、USキーボードレイアウトのみを考慮した実行コードが新たに記述されていたため、とりあえず、キーイベントが発生している、という程度の状況でした。
どんどん複雑化しているキーイベント仕様に対応するには、Windowsだけでコードを二つもメンテナンスするのはナンセンスですので、Bug-org 855975の修正で、デスクトップ版のnsWindowクラスから完全に分離されたwidget::KeyboardLayoutクラスと、widget::NativeKeyクラスをそのまま、MetroWidgetクラスで利用するようにしたことで、デスクトップ版と全く同じ結果を得られるように修正しました。
保護モードが無かった最後のバージョンである、Flash Player 10.3のサポートが、2013年7月9日に終了しました。代わりに、Flash Player 11.7が長期サポートの対象となります。なお、最新版は、Flash Player 11.8系になります。
これにより、Flash Player 10.3系を使い続けることは危険な状況となりました。JPCERTも警告を出しています。
Firefox利用中に、Flash Player 10.3系でトラブルが発生しないのに、11.7系でトラブルが発生する場合、多くのケースでは、Firefox上で実行中にのみ有効になっている保護モードの存在と、GPUによるハードウェアアクセラレーションで、GPUのドライバのバグに遭遇していることが原因となっています。
保護モードの解除に関しての説明も以前から公開していますし、GPUのドライバの更新や、もしくはハードウェアアクセラレーションの無効化についての説明も公開していますので、これらを参考に、至急、アップグレードすることを、強くお勧めします。
また、どうしてもFlash Playerが安定しない場合、特に、ブルースクリーンが出るような場合は、PCが古く、ドライバの更新が終了しているのかもしれません。その場合、PC自体の買い替えも検討された方が良いかと思います。Ultrabook等、メジャーなハードウェア構成のPCでしたら、ドライバ由来のトラブルが発生しても対応される可能性が高いですし、大半のハードウェアはIntel製なので、メーカーのサポートに関係なく、Windows Update経由や、Intelのサイトから直接、ドライバを更新することができます。
スラッシュドットのコメントを見ていても、憶測で色んなこと書いてる方が多いです。そのような情報に一人歩きされても困るので、あらためて、解説しようと思います。もし、この内容に間違いがあるなら、twitter等でリプライ頂けば修正します。
まず、基本中の基本ですが、WindowsのIMEというのは、ユーザのプロセス内で動いています(厳密には間違ってると思いますが、そこまで私も詳しくない)。図にすると以下のような感じ。
アプリのプロセスが作ったウインドウや、そのIMEのコンテキストに、IMEは自由にアクセスできます。システムにアクセスできるかは、アプリの実行権限に依存します。
伝統的なIMEはこのような感じですが、最近設計されたIMEは、外部プロセスに変換エンジン等を追い出し、プロセス間通信を行いながら動作するのが一般的になっています。これは、現在のプロセス間通信のコストと、メモリ利用効率を考えると、良いアプローチだと思います。
有名どころでは、Google日本語入力と、Baidu IMEが変換エンジンプロセスを別に起動していることが、タスクマネージャでも確認できます。
このような場合、通常のアプリでは、以下の図のように、IMEは、ホストアプリと、外部プロセスの両方にアクセスして動作することになります。
では、ここからは、Firefoxとプラグインの関係について見ていきましょう。
Firefoxは、クラッシュの統計をずっと取っていましたが、Firefox 3.6当時、その原因の大半はプラグインがFirefoxのプロセス内でクラッシュしていることにありました。これに対する解決策として、OOPPという仕組みを用意しました。
OOPPは、firefox.exeの外側に、plugin-container.exeというプラグインのホストプロセスを作り、クラッシュをこのプロセス内に押さえ込むことに成功しました。これを実現するために、plugin-container.exeは、firefox.exeのウインドウ上に、自分でウインドウを生成しフォーカスを持つことができます。このため、IMEは、plugin-container.exe内で動作することになりました。
ここで、Adobeは、Flash Player 11.3で、Firefox上で動作する場合にのみ動作する、特殊な保護モードを導入しました。
plugin-container.exe内に読み込まれたFlash Playerは、自前の保護されたプロセスを生成し、この保護されたプロセス自身がplugin-container.exeの生成したプラグイン用のウインドウの上に、自前のウインドウを生成し、フォーカスをこのウインドウが持つようになりました。このため、IMEも保護モードで起動されたプロセス内に読み込まれます。
ところが、この保護モードで動作するFlash Playerのプロセスは、外部プロセスとの通信は、悪意あるソフトがFlash Player内に侵入しているという前提に基づいているため、全て禁止しています。このため、外部プロセスを利用している、Google日本語入力や、Baidu IMEは、それに依存する機能を全て使えなくなってしまいました。
これが、この問題をAdobe以外が修正できないのか、という理由です。Google日本語入力や、Baidu IMEが設計をイチからやり直す、という解決策も無くはないですが、Adobe製品でしか問題ないことに対してやるような話ではありませんし、個人的には、Adobe側のIMEに対する理解が皆無だった、というところにあると思います。
ちなみに、カナロックがかからないのも、システムへのアクセスが制限されているために発生しているものと推測されます。
このような理由から、技術的には、過剰なセキュリティ対策を行っていると言える、Flash Playerの保護モードを無効化することが最も妥当だと、以前から主張してきました。この問題に悩まされているものの、保護モードの解除方法を知らない方は、解説している記事を参考に、解除された方が良いと思います。
ここまで、一般的なwindowedモードでの動作についての解説でした。では、windowlessモードはどうなのでしょうか?
以前、解説したように、実は、保護モードを利用していても、Google日本語入力や、Baidu IMEは利用可能です。
その理由は、windowlessプラグインの場合、フォーカスは、firefox.exeのウインドウが持っており、IMEもfirefox.exe内のものが利用されているためです。windowlessプラグインは、その結果だけを受けとります。
インラインで入力できなかったり、変換候補ウインドウがキャレット位置に表示されないのは、plugin-container.exeや、Flash Playerの保護モードプロセスから、firefox.exe内で動作しているIMEから未確定文字列を取得できないことや、表示位置をIMEに指定することができないためです。これらの問題は、プラグインとのインターフェースが不十分なために発生しているので、ブラウザ側の問題と言えます。
個人的な見解ですが、AdobeはFlash Playerの開発を今から行うなら、妥当な設計が行えると思います。おそらく、費用対効果から、日本のIMEを見捨てることになっているんじゃないかと思います。
Google Chromeの設計や、windowlessプラグインの設計に倣うなら、Flash Playerの保護モードプロセスは、自分でウインドウを作るべきではありません。フォーカスはplugin-container.exeのウインドウが取得し、IMEもこの内部で動かせば良いのです。そして、簡単に処理したイベントをプロセス間通信で、Flash Playerの保護モードプロセスに伝達すれば良いのです。そして、IMEにアクセスするために、保護モードプロセスから、plugin-container.exe内のFlash Playerに通信手段を用意しておけば、windowlessプラグインで発生するような問題は回避することができます(IMEが悪意あるソフトならどうなんだ、という意見も見かけますが、他のアプリでも利用するIMEの問題に対し、ひとつのアプリでのみ防御策を講じるというのはナンセンスです)。
いずれにしても、ユーザにとれる唯一の対策は、保護モードを解除すること以外にない状況が続くでしょう。
この記事に関して、CorvusSKKというIMEの開発者の方から連絡があり、IMEの外部プロセスと通信する際に使用する、名前付きパイプのセキュリティ設定を変更すれば、Flash Playerの保護モード内からも、通信可能になるという情報がありました。
Adobe側の説明と食い違っていて、驚いている所ですが、実際に動いているそうなので、NyaRuRuさんが、早速、Google日本語入力のオープンソース版である、Mozcで試してみるとおっしゃってます。
この話題で、初めて、明るいニュースが出てきました。
Windowsでは、XULのリッチリストボックスに、ネイティブのルック&フィールを、というバグです。スクリーンショット見てもらった方が速いですね。
Webページ上のリストボックスの表示は従来のままです。
Macではこれまで、DefaultKeyBinding.dictで設定された、システム全体で共有されているショートカットキーを無視し、Geckoで定義したショートカットキーしか利用できませんでした。
しかし、このバグの修正で、Gecko側が対応するコマンドを持っている場合に限り、DefaultKeyBinding.dictの設定が利用されるようになります。
例えば、Emacsライクなショートカットキーはこれによって定義されています。
MacOS X 10.5で、NSTextInputプロトコルがdeprecatedとなり、新たに、NSTextInputClientプロトコルが定義されていました。
このバグの修正により、NSTextInpuClientプロトコルもサポートするようになりました。
その結果、英数キー二度押しの際に、確定済み文字列が半角英数で置き換えられない、といった、一部のIMEの動作しなかった機能が、動作するようになっています。
NSInputManagerが、MacOS X 10.6でdeprecatedとなり、その代わりに、NSTextInputContextが利用できるようになりました。
このバグでは、NSInputManagerを利用していたコードを全て、NSTextInputContextで実現するように修正しました。
NSInputManagerは、何故か、Singletonのようなデザインになっているものの、フォーカスを持ったネイティブウインドウが変わると、別のインスタンスが返ってくる上、ドキュメント上は、そのインスタンスをキャッシュしないようにするようになっていて、変な存在でした。
それが、NSViewのインスタンスに関連づけられたNSInputContextのインスタンスをいつでも取得できるようになったので、コードが比較的、すっきりとしています。
Windows版のGeckoは、様々な処理を細かく、低レベルで処理するように進化していっているため、メッセージのハンドラを各モジュールが持っていて、nsWindowがそれらを呼び出す、という形になっています。
しかし、これらのハンドラの戻り値の意味が非常に分かり難く、また、ハンドラごとに独自に定義していて分かり難いため、widget::MSGResultという構造体を定義し、全てのハンドラでこれを利用するように修正しました。
今、原因が分からず、非常に困っている、Mac固有のバグです。
Macでは、パスワードフィールドがフォーカスを持つ間は、Secure event input APIを利用し、他のアプリからのキーイベントの監視を不可能にする必要があります。そして、このAPIのデザインが変なもので、パスワードフィールドがフォーカスを失う際に、これを解除して、通常の状態に戻す必要があります。
Geckoのように、ネイティブウィジットと、パスワードフィールドが1:1の関係になっていないアプリでは、非常にこの処理を慎重にこなさなくてはいけません。しかし、これにミスがあっても、まず、テスタが気付くことはないでしょう。そこで、Bug-org 807893の修正時に、この処理に失敗している際に、キー入力があると、リリースビルド以外、つまり、Nightlyビルドではクラッシュするようにしました。
そして現在、パスワードフィールドがフォーカスを持っている際に、secure event inputモードが有効になっていない、という一番、セキュリティ的にまずい状態が発生するケースがあり、クラッシュリポートが挙がってきている状況です。
クラッシュリポートを見ている限りは、ごく一部のユーザが繰り返し、このバグに遭遇しているようですが、クラッシュリポートにコメントを入力しているものは一件しかなく、その一件ではどういう状況で発生するのか、全く分からない状況です。
ですので、Mac版のテスタの方で、キー入力の瞬間にクラッシュした場合には、その直前に何をしていたのか、特に、フォーカスがどのように遷移したのか、できる限り、詳しく記述して、クラッシュリポートを送信してもらえるよう、お願いします。
以前、Bug-org 865566の修正において、KeyboardEvent.keyでのみ、ブラジルのポルトガル語キーボードや、Macの日本語版キーボードにある、テンキーのカンマキーのキーコードである、VK_ABNT_C2に対応していましたが、今回の修正は、KeyboardEvent.keyCodeや、KeyboardEvent.locationも、VK_ABNT_C2に対応させ、同時に、もうひとつの特殊キー、VK_ABNT_C1も対応させました。
この修正により、VK_ABNT_C2キーは、0x6C(108)になります。これは、GeckoのLinux版と同じキーコード値になるようにするためです。ちなみに、IEや、Windows版Chromeでは、0xC2(194)、Mac版ChromeやSafariでは、0xBC(188)になりますので、プラットフォームによって値の変化する、他のブラウザよりは正確に判定できるようにしています(Mac版ではまだ対応できていないので、Bug-org 897885に登録しています)。
VK_ABNT_C1は、ブラジルのポルトガル語キーボードの右シフトキーの左側にある文字入力用のキーで、/と?の入力キーです。このキーは、文字入力用のキーであると、widget::KeyboardLayoutに登録していませんでしたので、keyCodeが常に0になっていましたが、きちんと、/に対応したkeyCode値を返すようになっています。
Geckoでは、keydownイベントのpreventDefault()を呼び出しても、続いて、keypressイベントが発生する、というバグです。
Gecko 24までは、keydownイベントが消費された場合、defaultPreventedをtrueに設定して、keypressイベントを発火していました。
しかし、IE、Safari、Chromeではこの場合、keypressイベント自体が発火されません。
D3Eの仕様では、keydownイベントのデフォルトアクションに、keypressイベントが含まれていますので、Gecko以外のブラウザの動作が正しいことが明白です。
このため、今回の修正を行うことにしました。これにより、Webサイトや、Webアプリが影響を受けることはほとんどないと思います。なぜなら、他のブラウザの動作に合わせた修正だからです。
これに対して、FirefoxやThunderbirdのキー処理、アドオンのキー処理は、Geckoのこれまでの動作を前提に書かれている可能性がありますが、その場合、regressionが発生する可能性があります。
この修正により、regressionが発生する条件は、
keypressイベントがdefaultPrevented属性値を確認していない(常に動作する)keydownイベントがpreventDefault()を呼んでいる
というものになります。つまり、他の部分の処理に関係無く、強引に処理が行われる、keypressイベントハンドラがなければ、regressionは発生しません。
regressionが出た場合、その対処方法は、keypressイベントハンドラでkeyCode値を検査していたものはkeydownイベントハンドラで処理するようにする。
それ以外の、charCodeを見ているものに関しては、keydownイベントハンドラに移動できませんので、そのまま、動作しない形が好ましいと私は思います。なぜなら、他のイベントハンドラが、デフォルトアクションをキャンセルしているのですから、アドオンも含めたブラウザのデフォルトアクションは実行されるべきではありません。
ちなみに、Gecko内で、defaultPreventedを無視するのは、セキュリティに関わる部分です。例えば、開いたパネルやメニューが閉じることができなくなると問題ですので、このあたりは他の処理結果を無視して、強引に動作するようになっています。