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

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

もずはっく日記(2010年8月)

2010年8月5日

[ITmedia] Google、Waveの開発を中止 初回投稿日時: 2010年08月05日12時56分52秒
カテゴリ: Mozilla Core News 雑談
固定リンク: id=2010080500
リンク元: 0件
SNS: (list)

使ってませんでしたが、エンジニアというか、オタとしては非常に残念な結果だなぁと思います。話を聞く限りは面白そうだったので。

ただこれ、ブラウザのIMEの処理とは猛烈に相性が悪かったので少しほっとしています。

TSFが特に悩ましくて、IMEの変換中にコンテンツが書き換わるなんてことは想定していませんので(現在もあり得ない話ではないのですが、まずそんなコンテンツはほとんど無い)、ドキュメントのロック要請が非常に厳しい要求になっています

基本的にGoogleのWebサービスって高度なので、最近はIMEの処理周りのバグをGoogleに、もしくはGoogleで発見されるというパターンになってきています。まあ、単純なケースでは十分にバグが無くなってきているとも考えられますが、やっぱりGoogleのWebサービスのシェアが極端に大きいのかなぁとも思います。

2010年8月9日

Bug-org 519972 Move NSTextInput implementation to nsCocoaTextInputHandler 初回投稿日時: 2010年08月09日13時55分06秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010080900
リンク元: 0件
SNS: (list)

MacはAPIの仕様や、イベントモデルのアレな感じから、テキストの入力処理が非常に大きく、複雑です。また、OSのバージョンが上がるたびに仕様変更が激しく、他の処理と同じようにnsChildViewに置いておくのは得策ではない、ということで分離作業を開始しました。

まずは第一弾で、10.4のサポートのドロップ時に修正しきれていなかった不要なコードの修正が終わっています。

すでにベータステージなので、承認がおりるかどうかは不透明ですが、近日中に大きめの実際にコードを引き剥がすパッチを提出予定です。

Bug-org 569023 IME composition is committed unexpectedly when the focused window is hanging up on Vista and later 初回投稿日時: 2010年08月09日14時38分22秒
最終更新日時: 2010年08月10日11時40分11秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010080901
リンク元: 0件
SNS: (list)

Windows Vista以降ではウインドウになんらかの入力を行おうとした時に、そのプロセスがビジー状態だと、ウインドウ全体を白っぽく描画するようになっています。この時に、内部ではWM_IME_SETCONTEXTが送信され、一度IMEのコンテキストをdeactiveにしようとします(プロセスがビジー状態なのだから、この意義はよく分かりませんが)。Geckoはこのメッセージをフォーカスの移動だという前提で無条件に強制確定を行ってたため、なんらかの処理でFxがビジー状態に陥ると入力中の文字が確定され、辞書にも悪影響を及ぼしているかもしれない、という状況でした。

この修正では、まず、Geckoには直接関係のない、トップレベルウインドウへのWM_IME_SETCONTEXTは無視するようにしました。Deactiveなウインドウ内の子ウインドウがフォーカスを取得すると、最初にウインドウをアクティブにするためにトップレベルウインドウにフォーカスを与える処理が行われ、WM_IME_CONTEXTが送信されてしまいます。当然、このメッセージを処理する必要性はありません。

次に、wParamが非ゼロで、変換中のウインドウが他にあれば、これを強制確定するようにしました。GeckoはすべてのウインドウでひとつのIMEコンテキストを共有しているため、未確定文字列が他のウインドウで処理されるのを防ぐ必要があるためです(様々な理由から未確定文字列の持ち越しは行っていません)。つまり、wParamがゼロの場合には強制確定を行わなくなりました。

これにより、IMEの変換途中にFxのすべてのウインドウがdeactiveになっても強制的に確定されることはなくなりました。例えば、未確定文字列を適当に入力し、別のアプリケーションに切り替えて、再度、編集中のFxのウインドウをアクティブにすると、変換作業を継続できるようになりました(ただし、タイトルバー等の非クライアント領域以外をクリックしてアクティブにすると強制確定されてしまうので注意してください)。

さて、話はここで終わるはずだったのですが、パッチのテスト中によりややこしい話を見つけてしまいました。windowlessプラグインはフォーカスを失う際に強制確定を行ってくれません。これはWindowsアプリとしては正しいというか、より好ましい動作ではあるのですが、Geckoのローカルルールとの相性がすこぶる悪いのです。

対策として、windowlessプラグインのメッセージの中継処理のうち、IMEやキー入力に関連するものを丸ごとnsWindowからnsIMM32Handlerに移動し、windowlessプラグイン上でIMEの編集処理が完結しないままフォーカスの移動が発生した場合には強制確定を行うようにしました。

ところが、これだけでは新たにフォーカスを取得したウインドウ上に文字が入力されるというバグが発生してしまいました。Flash PlayerではWM_IME_COMPOSITIONWM_IME_CHARをきちんと処理していないようで、強制確定により、WM_CHARが生成されてしまい、これが新しいフォーカスウインドウで受信されていたのです。

これに対抗するために、WM_IME_CHARをプラグインに渡した後、処理されていない場合にはメッセージの内容を保存し、その後にWM_CHARを受信した時に同内容のものなら無視するようにしています。ただし、安全策として、もし内容の異なるWM_CHARを受信するとそれ以降のWM_CHARは無視しなくなるので、入力ができなくなる、といった問題は発生しないはずです。

今回の修正で、windowlessプラグインのIMEの状態もある程度はnsIMM32Handlerで監視するようになりました。このため、変換中かどうかの状態管理の変数が二重化されています。変換中かどうかの判定のためにstaticメソッドを用意しているので、変数を直接見ることとの意味の違いを知っておかないとバグを作り込んでしまうことになるので注意が必要です。

2010年8月21日

Bug-org 581576 hung up or too slow when press Enter key on Gmail editor which has a lot of misspelled words 初回投稿日時: 2010年08月21日13時03分33秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010082100
リンク元: 0件
SNS: (list)

Bug-org 552914の修正nsEditor::SetFlags()で常にスペルチェッカーの状態を最新状態に同期するようにしましたが、Gmailのエディタが思いの外、フラグの状態を変更するコマンドを発行していたため、ミススペルが異様に多いケースではハングアップに近いパフォーマンスの低下が発生していた、というバグです。

SetFlags()でフラグの差分がスペルチェッカーの状態に影響を与える可能性がある場合にのみスペルチェッカーの状態を更新するようにしました。これにより、普段の編集状態でSetFlags()がいくら呼ばれてもパフォーマンスには影響が出ないようになっています。

Bug-org 582893 IME isn't disabled when password fields on sheet dialog get focus 初回投稿日時: 2010年08月21日13時16分01秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010082101
リンク元: 0件
SNS: (list)

Bug-org 513952の修正によるregressionです。MacはフォーカスのあるビューのIME、キーボードレイアウトの状態しか変更できない、という恐ろしく不便な制限がAPIにあるため、パスワードエディタのキーボードレイアウトの制限や、その解除をタイマーを利用してフォーカスが完全に移動し終わってから処理するようにしています。

このときのフォーカスを持っているのかどうか、という判断に、ウインドウであるかどうかのチェックを入れていたものの、シートであるかどうかはチェックしていなかったので、シート上のビューはフォーカスを受け取ったと判断されることがないようになってしまっていました。

フォーカスの移動確認にシート上のものかどうか、という条件も付け加えたので正常に判定が行われるようになり、修正されました。

Bug 6761 [Mac] パスワード入力欄で二回連続でクリックすると、ロケーションバー、検索バーで日本語入力モードが選択不能になる 初回投稿日時: 2010年08月21日13時59分22秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010082102
リンク元: 0件
SNS: (list)

Bug-org 582893の修正中にたまたま発見したタイマーの初期化のバグがあったのですが、それの実害が、たまたま報告されました。それがこれです。

タイマーを仕掛けたまま、処理が完了するまでの間に再度、処理要求が来た場合に、タイマーをリセットし、もう一度タイマーを起動すべきだったのですが、リセットしたまま処理を中断していました。もともとの設計のとおり、タイマーをリセット後に再度、タイマーを起動するように修正しています。

アプリケーションのプラットフォームとして、プラグインがユーザには良くない理由 初回投稿日時: 2010年08月21日17時26分14秒
最終更新日時: 2010年08月21日17時32分01秒
カテゴリ: Software 雑談
固定リンク: id=2010082103
リンク元: 0件
SNS: (list)

スラドのFlashが消え去らない 6つの理由を読んでていろいろと思うところがあり、まとめておこうかなと思いました。

以前Flashの完成度について批判的なことをこの日記で書いたときに、はてブかどこかで、前時代的で時代錯誤な意見であるというコメントがつけられていましたが、原理的にプラグイン上にプラットフォームをもう一つ作ってしまうというのは時代に関係無くユーザにとってはあまり好ましい話ではないと考えています。

通常、シンプルなアプリケーションというのは各プラットフォーム(OS、またはtoolkit)の提供するGUI部品と、そのAPIを利用して作成されます。これが、そのプラットフォーム全体での統一されたUI、使い勝手を手軽かつ、確実に実現してくれます。このため、そのプラットフォームを使い慣れたユーザからすればもっとも自然な使い勝手を体験することができます。

しかし、モダンブラウザはこのような設計はとれません。理由のひとつはクロスプラットフォームな設計が求められることです。これによりAPIを直接利用するということはできず、やや遠回りな実装を行う必要があります。また、各GUI部品は各プラットフォームごとに何らかの制限がありますが、これがHTMLやCSSの仕様要求を満たすことはできませんので部品自体を独自に実装する必要があります。Geckoのチームはとにかく各プラットフォームに馴染むように日々、見た目や挙動の修正を行い続けていますが、まだまだ道半ばといったところです。この微妙な差異はユーザに違和感であったり、使いにくさにつながったりします。つまり、この時点でひとつ、ネイティブな動作との乖離が発生してしまっています。

さらにこの上で動くWebアプリケーションがHTML/CSS/Javascriptで独自のUIを作ったとしましょう。この場合、オリジナリティ溢れるUIでさらにユーザに違和感を与え、それを不便と感じる人も少なからずいるでしょう。

さて、では本題、プラグインについて考えてみましょう。プラグインのUIには大きく分けて二つの形が考えられます。

ひとつはAdobe ReaderのようにWindowedモードのみに割切り、プラグインウインドウの上に、各プラットフォームネイティブのGUIパーツを配置してしまうプラグインです。ブラウザよりもよりプラットフォームネイティブな動作を実現できるのでブラウザの違和感すら消してくれる可能性があります。これは一部のユーザには好ましいかもしれません。しかし、ブラウザとプラットフォームの差異に慣れてしまったブラウザのユーザには、逆効果の可能性もあります。ブラウザのウインドウ内なので、ブラウザのGUI仕様で操作しようとしたのに、ブラウザとは違うプラットフォームネイティブの挙動を体験してしまうからです。考えていたことと違う結果になるのはストレス要因となるでしょう。

もう一つは、Flashに代表されるようにアプリケーションのプラットフォームとして、独自のGUIパーツをプラグインウインドウ上に描画し、動作するプラグインです。この方式であればWindowlessモードでも問題ありませんし、プラグインのクロスプラットフォーム化が容易になります。つまり、モダンWebブラウザと同じアプローチになります。ですが、ユーザからすると、プラットフォームとも、ブラウザとも挙動の違うGUIが提供されることになり、さらなる学習、不便を強いられることになります。

さらに、こういったプラグイン上でアプリケーションが独自にUIを提供してしまうと、さらに新しいGUI仕様ができあがり、ユーザにとってはさらなる負担になります。

表にすると以下のようになります。

ユーザの体験するアプリケーションそこまでのGUI仕様の移り変わり
  • ネイティブアプリケーション
  1. プラットフォームのみ
  • 静的なWebページ
  • 独自UIを提供しないWebアプリケーション
  1. プラットフォーム
  2. Webブラウザ
  • 独自UIを提供するWebアプリケーション
  1. プラットフォーム
  2. Webブラウザ
  3. Webアプリケーション
  • ネイティブGUIを利用するプラグイン
  1. プラットフォーム
  2. Webブラウザ
  3. プラットフォーム
  • 独自GUIのプラグイン
  • アプリケーション独自のGUIを提供しないプラグインアプリケーション
  1. プラットフォーム
  2. Webブラウザ
  3. プラグイン
  • アプリケーション独自のGUIを提供するプラグインアプリケーション
  1. プラットフォーム
  2. Webブラウザ
  3. プラグイン
  4. プラグインアプリケーション

基本的に、GUI仕様の移り変わりが多ければ多いほど、ユーザに違和感を与えることになると考えられます。

またGUIイベントを処理する各レイヤーごと(プラットフォーム、ブラウザ、プラグイン)にそれぞれバグを持っていると考えられます。つまり、よりユーザに近いレイヤーほど様々なバグを内包していることになり、問題が発生しやすくなります。これは食物連鎖の生物濃縮と似ています。

例えば、「ネイティブGUIを利用するプラグイン」を除き、GUIに発生したイベントはブラウザ経由で発生します(OOPじゃない場合はwindowlessモードではない限り、フォーカスを持っていれば直接発生します)。イベントが中継される場合、パフォーマンスの問題からブラウザ側でイベントの取捨選択が行われます。もし、ここに問題があると、IMEがwindowlessモードでは使えなかったりするような問題が発生します。つまり、プラグイン独自UIはブラウザのプラグインとの通信部分にバグがあると、それだけでうまく動かなくなります。なんらかの処理を行うレイヤーが増えれば増えるほど不利になるのは当たり前の話ですが、この話の場合、それが非常に顕著です。

アンフェアな話なので、プラグインを推したい人からすると不愉快な内容だと思いますが、プラグインがアプリケーションの実装の仕方として不利なのはその立場上、仕方のないことです。

プラグインがHTML/CSS/Javascriptでは実現できないことの解決手段であるというのは事実ですし、あるプラグインの普及率が高い限り、そのプラグインがこの目的で利用されることは十分考えられるので、プラグインが要らない世界、というのは永遠に来ないのではないかと思います。

ただ、上述のようにプラグインにはその立場上、技術的に不利な点が目立ちます。プラグインを利用せずとも実装できることはプラグインを利用しない、また、特に重要ではない何かをあきらめることで、プラグインを利用せずに済む場合もプラグインを利用しない、これがWebページの提供側にとって一番良い判断ポイントだと思います。

各所でのFlashに対する不満や支持に関するコメントを見ていると、ユーザはFlash(もしくはFlashとブラウザとの連携部分)に文句を書き、Webサイトの開発者は開発のしやすさから支持しているように見えます。もしこの印象が正しいのであれば、まるで「永田町の常識、世間の非常識」のように、ユーザの感覚がないWebコンテンツ開発業界という残念な状況あるのかもしれません。

2010年8月25日

ジェネレーションギャップ 初回投稿日時: 2010年08月25日00時20分53秒
カテゴリ: 雑談
固定リンク: id=2010082500
リンク元: 0件
SNS: (list)

ちんどん屋』を知っているかと話を振ってみたところ、やっぱり高校生以下は知らないみたいで、予想はしていたものの軽くショック。ちなみに、私も実際に見たことはほとんどありません。

2010年8月26日

Bug-org 560071 Improve IME selection painting 初回投稿日時: 2010年08月26日13時10分49秒
カテゴリ: Mozilla Core バグ検証中
固定リンク: id=2010082600
リンク元: 0件
SNS: (list)

他の作業に区切りがついたので長らく中断していたこのバグに戻ってきましたが、自動テストを書いていると悩ましい問題が。

IMEの未変換文字列の各文節のスタイルはIMEからも指定できるようになりましたが、以下のようなケースでどうしたものかと悩んでいます。

選択文節の背景色が黒、前景色が白、それ以外の文節の背景色が白、前景色が黒を指定してくるIMEがあったとします。このIMEが黒い背景色のエディタで動作する場合、色を反転させないと、選択文節は背景色黒に溶け込んで目立たなくなってしまいます。ですが、単に選択文節の背景色が背景色と十分なコントラストを得られない場合に前景色と入れ替えた場合、選択文節の文字自体は背景色に対してコントラストが十分になりますので、選択文節しか無い状態だとこれで良いのですが、非選択文節がある場合、同じ色になってしまって文節の区切りが分からなくなります。

非選択文節が無い場合のみ、選択文節の色を反転させる、という手もありますが、この場合、文節の数によって表示色が変わってしまい、良くありません。

今のところ、非選択文節の背景色に透明色以外をデフォルト設定で指定してくるIMEは無いようなので、背景色指定があれば常に反転させる、というのがひとまずの現実的な解なのでしょうか……

Bug-org 560071 Improve IME selection painting #2 初回投稿日時: 2010年08月26日22時30分03秒
最終更新日時: 2010年08月26日22時31分08秒
カテゴリ: Mozilla Core バグ検証中
固定リンク: id=2010082601
リンク元: 0件
SNS: (list)

整理のために表にしてみるとこんな感じです。分かりやすくするために、未確定文字列には下線をつけておきます。

各文節のスタイルイメージ
  • エディタの背景が白に指定されている
  • 全体がひとつの文節で、選択されている
  • 文節の背景色は黒、前景色は白が指定されている
確定済み選択文節
  • エディタの背景が白に指定されている
  • ふたつの文節があり、ひとつめが選択されている
  • 選択文節の背景色は黒、前景色は白が指定されている
  • 非選択文節の背景色は白、非選択文節の前景色は黒
確定済み選択文節非選択文節
  • エディタの背景が黒に指定され、前景色には白が指定されている
  • 全体がひとつの文節で、選択されている
  • 文節の背景色は黒、前景色は白が指定されている
確定済み選択文節
  • エディタの背景が黒に指定され、前景色には白が指定されている
  • ふたつの文節があり、ひとつめが選択されている
  • 選択文節の背景色は黒、前景色は白が指定されている
  • 非選択文節の背景色は白、非選択文節の前景色は黒
確定済み選択文節非選択文節
  • エディタの背景が黒に指定され、前景色には白が指定されている
  • 全体がひとつの文節で、選択されている
  • 文節の背景色は黒、前景色は白が指定されている
  • 選択文節がコントラスト不十分な場合に反転を行う
確定済み選択文節
  • エディタの背景が黒に指定され、前景色には白が指定されている
  • ふたつの文節があり、ひとつめが選択されている
  • 選択文節の背景色は黒、前景色は白が指定されている
  • 非選択文節の背景色は白、非選択文節の前景色は黒
  • 選択文節がコントラスト不十分な場合に反転を行う
確定済み選択文節非選択文節
  • エディタの背景が黒に指定され、前景色には白が指定されている
  • 全体がひとつの文節で、選択されている
  • 文節の背景色は黒、前景色は白が指定されている
  • コントラスト不十分な全ての文節で反転を行う
確定済み選択文節
  • エディタの背景が黒に指定され、前景色には白が指定されている
  • ふたつの文節があり、ひとつめが選択されている
  • 選択文節の背景色は黒、前景色は白が指定されている
  • 非選択文節の背景色は白、非選択文節の前景色は黒
  • コントラスト不十分な全ての文節で反転を行う
確定済み選択文節非選択文節
  • エディタの背景が白に指定され、前景色には黒が指定されている
  • ふたつの文節があり、ひとつめが選択されている
  • 選択文節の背景色は黒、前景色は白が指定されている
  • 非選択文節の背景色は白、非選択文節の前景色は黒
  • コントラスト不十分な全ての文節で反転を行う
確定済み選択文節非選択文節

非選択文節と、選択文節には明確なコントラストがなければ選択文節が分かりにくくなり、操作に支障が出ます。また、未確定文字列全体が明確に未確定文字列だと分からない場合もやはり操作に支障が出ます。

問題は、TSFにしてもGTK2にしても、各文節ごとにスタイルが指定できるので、存在しない文節に関してはどのような色が利用されるのか想像もできない点です。つまり、他の意味を持つ文節の情報は、現在存在するものに関してしか分かりませんので、一回の変換のトランザクション内で安定した表示結果を出すことは難しいのです。

こうなると、やはり単純に各文節ごとにより良いロジックでコントラストを確保していくしか無いように思えます。

上記の例では同じ基準で、非選択文節と選択文節を反転させてしまっているので、これらの間にあるコントラストが仇になり、結果として同じ色での表示となってしまっています。であるならば、選択文節は今まで通りの反転を行い、非選択文節ではコントラストがありすぎる場合にのみ反転させる、というのであれば大半のケースでは問題無いのかもしれませんね(今、まさに、書きながら思いついたことです)。

2010年8月27日

Bug-org 560071 Improve IME selection painting #3 初回投稿日時: 2010年08月27日00時17分11秒
最終更新日時: 2010年08月27日00時23分41秒
カテゴリ: Mozilla Core バグ検証中
固定リンク: id=2010082700
リンク元: 0件
SNS: (list)

もっと単純に考えて、選択文節の色を反転させる場合は全ての文節の色を反転させるべきなんですかね。最悪のパターンでは最初に変換を行って、初めて選択文節が生成されるときに反転が初めて発生して違和感がでるかもしれませんが。

各文節のスタイルイメージ
  • エディタの背景が黒に指定され、前景色には白が指定されている
  • 全体がひとつの文節で、選択されている
  • 文節の背景色は黒、前景色は白が指定されている
  • 選択文節のコントラストが不十分な場合に全文節を反転
確定済み選択文節
  • エディタの背景が黒に指定され、前景色には白が指定されている
  • ふたつの文節があり、ひとつめが選択されている
  • 選択文節の背景色は黒、前景色は白が指定されている
  • 非選択文節の背景色は白、非選択文節の前景色は黒
  • 選択文節のコントラストが不十分な場合に全文節を反転
確定済み選択文節非選択文節

こんな感じ。下線が無ければこの例の場合、未確定文字列か確定済みかの判断がつかなくなってしまいますが、選択文節の境界さえ分かれば操作には支障がないはずなので、これでOKですかね。

Bug-org 562195 Shortcuts do not work in Qt Fennec 初回投稿日時: 2010年08月27日10時37分39秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010082701
リンク元: 0件
SNS: (list)

Qt版key hellです。Qtだとショートカットキーが動かない、ということでアドバイスを求められましたが、担当者への説明だけでメールでのやりとりに数日かかった上に、Qtが全然低レベルな情報を提供してくれていないので、X11のAPIを直接叩くはめになったり、途中で担当者が反応無くなって別の人が引き継いだりとか、色々とあった末にようやく修正されました。

イベントドリブンみたいな感じでどうにかkey hellの基本動作をXP化できないものかと思案中ですが、なかなか効率の良い形は思いつかずです。

Bug-org 560071 Improve IME selection painting #4 初回投稿日時: 2010年08月27日11時21分36秒
カテゴリ: Mozilla Core バグ検証中
固定リンク: id=2010082702
リンク元: 0件
SNS: (list)

よくよく考えてみると、複数の要素にまたがって未確定文字列が存在する場合がありました。HTMLエディタで複数の要素(背景色)にまたがってテキストを選択し、再変換を開始するとおかしなことになります。

実際問題、複数のブロックレベル要素をまたいでそのような状況になることはないので、未確定文字列全体を包含するブロックの背景色から反転処理を行うかどうかが合理的でしょうか。

Bug-org 560071 Improve IME selection painting #5 初回投稿日時: 2010年08月27日17時00分15秒
カテゴリ: Mozilla Core バグ検証中
固定リンク: id=2010082703
リンク元: 0件
SNS: (list)

ちょっとテストケースを作って見たところ、再変換が開始されるときに選択範囲の先頭の要素内に未確定文字列がすべて吸い込まれてしまう模様。ということは、折り返しによって生成される複数のtextframeに未確定文字列が分散することがあっても、複数の背景色が未確定文字列の背後に来ることはなさそうです。

2010年8月28日

Bug-org 581764 [IMM32] Sometimes ATOK failed to initialize Kana-Nyuryoku mode #2 初回投稿日時: 2010年08月28日14時33分56秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010082800
リンク元: 0件
SNS: (list)

ATOKのカナロックが勝手に解除されてしまう問題ですが、1.9.2.10にも入りました。これで、Fx3.6.10では修正されます。

ただ、まだ再現することはあるので、他の再現パターンがあるようです。もし新しい再現方法を見つけた場合は新しいバグを登録してください。