断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。Corporation、及び関連企業の公式情報ではないことに注意してください。(もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。修正していく予定ですのでしばらくお待ちください。(list)最初に断わっておきますが、これはユーザがどうこうする話ではなくて、Web開発者向けの話です。利用しているサイトでこの問題で困っていて、保護モードを切るのに抵抗がある方は、このエントリをそのサイトの運営者の方に報告してください。すると対策をとってくれるかもしれません。PlayerはFirefox上で動く場合にのみ、保護モードという、内部処理を権限が制限されたプロセスで動かすモードを有効にして動いてることは、これまで何度かここに書いてきました。(もちろん非公式)も参照してください)。ユーザ側での対抗策として、これまでは保護モードを無効にすることを紹介していましたが、今回、テスト中にたまたま見つけた、Webサイト側でとれる対策を紹介します。modeそれぞれのプラグインの構造を参照してください)。Flashコンテンツを作るツールを持っていないので、bugzilla-jpに添付されていたswfファイルを拝借してきました。実際に、Webコンテンツを作られている方は、wmodeを指定するparam要素を挿入するかどうかは、UA名にFirefoxが含まれているかどうか、Windows版かどうか、この二点を確認した上で挿入した方が良いでしょう。一般的に、windowlessモードは各ブラウザの実装のバラツキが大きいためです。(windowlessモード)なぜこれで、IMEに関する互換問題が一掃されるのか、その理由は簡単です。Player自身がネイティブウインドウをFirefoxの上に保護モードで作り、このウインドウがフォーカスを持ち、入力されたメッセージを保護モードで処理します。このため、IMEは保護モード下で動作し、上述の制限を受けることになります。Playerのプロセスは自分自身でウインドウを生成しません。Flashの内容が、Firefoxのウインドウ上に、直接描画されるモードだからです。このため、IMEのイベントを受け取るのはFirefox自身のウインドウになります。これはつまり、IMEは保護モードの外、Firefoxのプロセス内で動作します。このため、通常の権限でIMEが動作することになります。Firefoxは、受け取ったIMEのイベントを、内部処理専用のDOMイベントを利用して、フォーカスを持ったwindowlessプラグインのプロセスへ渡します。これにより、IMEがFlash上でも使えるのです。一つだけ、このwindowlessモードには欠点があります。それは、on-the-spotでIME経由で入力できないということです。未確定文字列が、点滅するキャレットの位置に描画されません。これは、Windowsでは、アプリ自身が未確定文字列を描画する場合や、候補ウインドウ位置を指定する時にはWindowsのAPIを通じて、動作中のIMEのコンテキストにアクセスしなければいけないのですが、別プロセスのコンテキストにアクセスすることはセキュリティ上、できないため、このようなことになります。この件に関しては、そのうちに、プラグインの描画領域のすぐ下にでも表示されてマシになるように、対策はとりたいとは考えています。関連するかもしれないエントリ関連するかもしれないエントリを発見できませんでしたが、無いとは限りません。