Opera is bad #2

しかしそうも言っていられない。Opera が対応している keypress、keydown、keyup、input イベントでなんとか擬似的に composition events を再現できないか。

ということでそれっぽくできた。一応このエントリも、今まさに wasavi で書いている。しかし問題は山積している:

  • 結局のところ、例の暗黙的確定には対応できない。
  • 上記のイベントの、Opera 12.12 上での動作にきわめて依存した構成なので、安定してるともいえない。

つまり人様にお出しするにはちょっと……という出来である。どうしよう。

ちなみに擬似 composition events の実現手法だが、Opera で IME の仮入力は、keydown、input、keypress の順でイベントが発生する。このとき、input イベントは場合によっては複数回発生する。仮入力中は、keydown 時の keycode は 229 で固定。keyup 時の keycode は本来押されたキーのコードが入っている。

IME がアクティブな時の様々な動作の特徴は以下の通り:

  • 明示的確定: 仮入力後変換候補を出している状態で、enter キー押下により確定する動作。keydown(229)、input が 2 回、keyup(13)
  • 暗黙的確定: 仮入力後変換候補を出している状態で、変換に使用しないキーの押下により暗黙的に確定する動作。たとえば「漢字」と変換した状態でそのまま続けて HENKAN と打つと、「漢字」は自動的に確定され、かつ確定に使用した文字「H」が次の仮入力に持ち越される。この動作は composition events でなければ正しく認識できない。keydown(229)、input が 3 回、keyup(暗黙的確定に使用した文字のキーコード)
  • 仮入力の取り消し: 取り消しには 2 パターンの方法がある。escape キーを押すか、backspace で仮入力文字を全削除するか。前者は keydown(229)、keyup(最後に入力した文字のキーコード)。つまり input イベントが発生しない。後者は発生する。さらに、IME がアクティブで、かつ仮入力文字列が空かどうかで判断する
  • その他の仮入力、変換操作: keydown(229)、input が 1 回、keyup(最後に入力した文字のキーコード)

keydown、input、keyup をリスンし、keydown 時のキーコードおよび input が発生した回数を覚えておく。上記の場合分けはすべて keyup のハンドラで行う。

その他の仮入力、変換操作で、IME がアクティブ(これは実際の IME の状態ではなく、javascript 上のフラグ)でなければ、compositionstart イベントを発火し、IME がアクティブ状態であるとする。それから、compositionupdate イベントを発火する。

2 種の確定動作で確定された文字列を取り出し、compositionend イベントを発火し、IME が非アクティブ状態であるとする。

Opera is bad

UAX #14 に準拠した段落の再フォーマットを実装したということは、つまり日本語を初めとする latin-1 以外の文字を含んだ段落もそれなりに処理してくれるということなのだが、さて wasavi と日本語の入力という点を考えてみると、要するにというか例によってというか DOM3 Composition Events の話になるのだが、一応実装してあるものの、あまり詰めているわけではない。これはいまだに Composition Events を実装していない Opera が悪い。

Composition Events の他に、エクステンションからシステムのクリップボードを読み書きすることも Opera 版 wasavi ではまだ不可能だ。Opera が悪い。

辛うじて、Opera も input イベントは実装しているので、擬似的に compositionend イベントをエミュレートすることはできなくもない。しかし前にも書いた気がするが、これだと仮入力して変換候補を出している状態で、変換に使用する以外のキーを押して暗黙的に確定をした際の正確なタイミングをキャッチできない。Opera が悪い。

あまりエラソーなことも言いたくないが、Opera の中の人は IME を使用する言語圏のことはどうでもいいの? やる気ないの? 特に Opera の日本支社のヒトは何をしているの? と思わざるを得ない。みすみすニーズを逃している。Opera が悪い。

Composition Events が実装されるのを待って、かれこれ 3 年になろうとしている。そういえば XMLHttpRequest#overrideMimeType が実装されるまでにも相当待ったのを思い出した。もうちょっと開発者の声に耳を傾けていただきたいものだ。

Opera が悪い。

a new version “marlin” is approaching fast

Opera 12.50 だそうです。

Clipboard APIDOM3、その他を実装するとか。

おお wasavi を動かす上で他のブラウザから遅れている機能が一気に揃うとは……! Composition events も実装するとは確約されていないけど、実装されれば Opera でも wasavi がちゃんと動くようになるなあ。

その他、Opera Labs では SPDY 対応ビルドが公開されている。へー。

 * * *

インストールして試してみた。Composition event が発生しないじゃないですかー! やだー!

Opera 12 is landed

Opera 12 がリリースされた。

せっかくなので、64bit 版をインストールしてみた。

32bit から 64bit へ自動的に移行とかはしてくれない。32bit 版をアンインストールして 64bit 版をインストールした(といっても排他的ではなく両方同時に実行可能だと思うけど)。

プロファイルに完全な互換性があるのかは不安だったので、新しいプロファイルを生成させた後、wand.dat とメール関連のファイルだけを元の 32 bit 版から移植した。wand.dat はだいたい以下のような感じの場所にある:
C:\Users\akahuku\AppData\Roaming\Opera\Opera_x86
akahuku とか Opera_x86 とかは適宜自分の環境に置き換えるべし。ふつうは Opera_x86 じゃなくて単に Opera だと思う。
メール関連は Roaming ではなく
C:\Users\akahuku\AppData\Local\Opera\Opera_x86
内の mail ディレクトリに入っている。アカウント情報とかも入っている。したがって単に mail ディレクトリを x64 版側のプロファイルへ移動させれば移行完了。また、Local プロファイルには widgets ディレクトリという extension のデータも入っている。これも x64 版プロファイルへ移動させれば移行できると思うが、未確認。

とりあえずこれで 64bit 版 Opera を起動させ、あとはちまちまと設定しなおす(フォントとか)。それでも Opera Link のおかげでいろいろと手作業での移行も楽になっている。

というわけで 64bit 版 Opera 12.00 で書いているのであるが。とりあえず気付いたところは:

  • 終了時にプロセスが完全に消えるまで何やらゴリゴリとディスクアクセスして、下手すると完全終了まで 30 分くらいかかることがあったのが、今のところすんなり終了するようになった。64bit 化の恩恵なのか、12 で修正されたのか、インストールしたてだからなのかは不明
  • 全体的には速くなってると思う。たぶん
  • Hardware Acceleration が実験的に実装されているが、うちの環境(gforce 9500 GT)では Direct3D バックエンドが有効になるものの、なかなかに不安定。あと、H/A 環境ではフォントのレンダリングが薄味になって見にくい
  • Opera と関係ないのだが、IE9 が何をどうやってもページを互換モードで開く動きをして困っていたのが、32bit Opera をいったんアンインストールしたらそれがなくなった。アンインストールしたと同時にデフォルトのブラウザの切り替えをしたと思うのでそのときにうまい具合に何かが初期化されたのか?
  • スクリプトやら iframe の広告やらがてんこ盛り系のサイトでよく起きていた気がするのだが、ページ遷移の履歴に不明な空履歴が複数入ることがあって、つまり何回も「戻る」を押さないと、本来の遷移元ページに戻れないことがよくあった。それが直っているような気がする

ところで DOM3 Composition Events は……。