MozillaZine.jp フォーラム https://forums.mozillazine.jp/ |
|
文字入力ができなくなる https://forums.mozillazine.jp/viewtopic.php?f=2&t=16316 |
ページ 1 / 1 |
作成者: | Катюша [ 2016年10月04日(火) 17:42 ] |
記事の件名: | 文字入力ができなくなる |
(使用環境) Firefox 49.0.1(32bit)をWindows 10 Pro(64bit)で使用しています 現在環境が変わっていますが、本現象はFirefox 48.0.0(32bit) Windows 7 Pro(64bit)環境の頃から発生しています Windows 10は新規PCへの新規インストールです (発生している事象) Windows ロック画面、Excel、メモ帳等で突然文字入力ができなくなり、放置しておくとしばらく経ってから回復する 但しFirefoxを終了すると直ちに回復する (関連がありそうなアプリ) Kaspersky Internet Security 2016(Ver 16.0.1.445) ATOK 2016 文字入力ができなくなった時に、ctrl+shiftでMS-IMEに変えても回復しない Kasperskyにも問い合わせを行ったが、Firefox 42以降は現在サポート対象外とのこと 対応策やご助言等よろしくお願いします |
作成者: | WADA [ 2016年10月04日(火) 20:17 ] |
記事の件名: | Re: 文字入力ができなくなる |
Катюша さんが書きました: (発生している事象) Windows ロック画面、Excel、メモ帳等で突然文字入力ができなくなり、放置しておくとしばらく経ってから回復する 但しFirefoxを終了すると直ちに回復する Mozillaファミリーの中だけで、ウィンドウAで文字入力中に、あるイベントでトースターポップアップのような別ウィンドウBが開かれ、そのウィンドウBが自動で閉じられた後、 元々のウィンドウAにはフォーカスが戻らず、別のウィンドウCにフォーカスが行ってしまうので、キーイベントがウィンドウCに行ってしまう、 というようなものならば、Thunfderbirdでは比較的簡単に起こって、Firefoxでも同じようなことがあるので、Mozillaファミリーの基本の部分の問題である、と認識されているバグがあります。 Thunderbirdにおいて典型的なものが、 コンポーザーのウィンドウが最前面にあってタイプしている時に、 新着メールなどでトースターポップアップが表示されて、そのトースターポップアップが自動的に閉じられたあと、 最前面ではないThunderbirdのメインウィンドウ(messengerウィンドウ)にフォーカスが行ってしまうので、 キーイベントはThunderbirdのメインウィンドウ(messengerウィンドウ)に行ってしまう、 けれども、画面では、コンポーザーが最前面のままなので不可解な現象であり、コンポーザーのウィンドウでクリックしないといけない、 というものです。 [ Bug 942610 ]で、この中には、Firefoxのものも含めた他のバグへのポインターもあります。 Mozillaファミリー以外の他のアプリケーションのウィンドウからフォーカスを奪ってしまうことは、何らかのイベントでトースターポップアップのようなものを表示したときに起こる、とは思いますが、 そのあとで、アプリケーション間での、最前面のアプリケーションのウィンドウにフォーカスが戻れば、おっしゃるような現象にはならないように思えます。 Mozillaファミリー(or Thunderbird)内だけについては、Bug 942610 で、NSPR_LOG_MODULES=WidgetFocus:5,Focus:5,timestamp でNSPRログをとってみてくれ、というリクエストがでたところで、まだ進展はありません。 似たような現象だ、というだけで、Bug 942610 がКатюшаさんのところで起こっている現象に関係するのかどうか、一切不明ですが、ご参考までに。 |
作成者: | Катюша [ 2016年10月05日(水) 16:52 ] |
記事の件名: | Re: 文字入力ができなくなる |
WADAさん、レスありがとうございます。 Excelやメモ帳上でカーソルが点滅している状態で文字入力ができず、その状態でスクリーンキーボードからは文字入力ができるので、 ご紹介いただいた事象とは異なる事象が発生しているようです。 何かが影響を与えているのでしょうが、現時点でわかっているのは 突然[b]文字入力ができなくなるという不具合発生時に、Firefoxを閉じると問題は即時に解決し、 再度Firefoxを起動してもしばらくは文字入力ができるというところです。 [/b] |
作成者: | 偶然的通行人 [ 2016年10月06日(木) 20:38 ] |
記事の件名: | Re: 文字入力ができなくなる |
横から失礼します。 ぼくは専門的な知識を持ってないので、エンドユーザーの経験範囲でしか述べられませんが、ちょっと別の観点から......。 Катюша さんが書きました: (使用環境) Firefox 49.0.1(32bit)をWindows 10 Pro(64bit)で使用しています 現在環境が変わっていますが、本現象はFirefox 48.0.0(32bit) Windows 7 Pro(64bit)環境の頃から発生しています Катюша さんが書きました: (関連がありそうなアプリ) Kaspersky Internet Security 2016(Ver 16.0.1.445) ATOK 2016 Windows 10 Pro (64bit) も、Windows 7 Pro (64bit) も、標準の日本語入力システムとして ATOK をお使いですか。 もしそうだとして、Windows 7 Pro (64bit) でも ATOK 2016 をお使いでしたか。 Катюша さんが書きました: (発生している事象) Windows ロック画面、Excel、メモ帳等で突然文字入力ができなくなり、放置しておくとしばらく経ってから回復する 但しFirefoxを終了すると直ちに回復する このあたりの事情について、下記の点はどのようになっていますか。 (a)OS 起動時、標準の日本語入力システムとして ATOK が起動している、ということですよね。 (b)OS 起動後、Firefox を起動しなければ、Excel やメモ帳などで突然文字入力ができなくなる現象は起こらないのですか。 (c)起動している Firefox では、どのようなタブが開かれ、どのようなサイトを読み込んでいますか。 (d)Firefox を起動後、Firefox 上で文字入力をおこなったか否かで、症状に変化はありますか。 (e)Firefox 上(検索バーとか Web ページのフォームとか)で、文字入力ができなくなることはないのですか。 Катюша さんが書きました: 文字入力ができなくなった時に、ctrl+shiftでMS-IMEに変えても回復しない OS 起動の最初から、ATOK ではなく Microsoft IME を使用した場合でも、文字入力ができない症状は発生しますか。 今はっきり区別できる条件を整理して、できるところから問題点の切り分けを進めてみてはいかがでしょう。 (考察) 日本語版 Windows における文字入力の基軸は日本語入力システムにあるので、文字入力ができなくなるということは、日本語入力システムに何らかの問題が起こっていることが推測されると思います。 一方、「Firefoxを終了すると直ちに回復する」とのことなので、Firefox が何らかの影響を及ぼしている可能性が考えられるため、このフォーラムに質問なさったのだと思います。 そのことをふまえた上で、Firefox 上での文字入力ではなく、別アプリケーションでの文字入力に際して動作不良が起こるのなら、Firefox 側からだけでなく、日本語入力システムの側からの原因究明も視野に入れたほうがいいのではないかと思います。 このような観点から、ひとまず OS 標準の Microsoft IME と ATOK で、現象の再現性を比較してみてはいかがでしょうか。 (既出の条件から気になること) Microsoft IME でも発生する問題なら以下は意味がありませんが、ATOK 2016 を前提にした場合の気になる点を書いておきます。 ぼく自身は ATOK を常用していませんが、例えば ATOK 2016 についてはいくつか評判を耳にしてます。 今の段階で本件と関係あるかどうかわかりませんが、ATOK 2016 の新機能「ATOKインサイト」(初期状態で有効らしい)が、文字入力の動作を極端に重くしてしまうケースがあるという話です。 (「ATOKインサイト」機能の概要) ・日本語入力システム ATOK 2016 for Windows | ジャストシステム >> 最適な候補を表示「ATOKインサイト」 http://www.justsystems.com/jp/products/ ... html#scene もし、Firefox 上に表示されている文章を解析する ATOK の動作に問題が起こったと仮定すると、実際に文字入力をしている Excel やメモ帳などでの入力操作に対して反応しなくなることがあるのかもしれません。 「放置しておくとしばらく経ってから回復する」というのは、一定時間(timeout など)を経て ATOK の異常状態が強制解除されたということかもしれませんし、Firefox を終了させると(停滞していた)解析処理が打ち切られ、問題が直ちに解消するのだと考えれば、理屈としては説明できそうにも思われます。 もちろん、「ATOKインサイト」が正常に機能するユーザー環境はあるわけですから、それが普遍的な原因だとはいえませんが、仮に「ATOKインサイト」に起因する問題だったとすれば、問題が起こるユーザー環境にトリガーとなる何らかの要因が潜んでいるのかもしれません。 そのひとつとして Firefox が関与しているかどうかの切り分け、関与があったとしてどの部分が問題なのかは、ATOK の動作をふまえて Firefox 側で点検作業をすることになると思います。 可能性のひとつとして、「ATOKインサイト」の機能をひとまず無効化し、動作を確認してみてはいかがでしょうか。 他にも、ATOK 側の設定等を見直すことで、ATOK 本来の効率のいい文字入力を取り戻せるかもしれません。 Катюша さんの事例に当てはまるかどうかはわかりませんが以上です。的外れな話だったらすみません。 |
作成者: | Катюша [ 2016年10月07日(金) 20:05 ] |
記事の件名: | Re: 文字入力ができなくなる |
通行人さん、レスありがとうございます。 Win7及びWin10でATOKを標準IMEとして使用しています。 ATOKは発売日である2016年2月から使用しており、Firefox 47.0.1までは文字が入力できなくなるということはなく、 Firefox 48.0.0以降に不具合が発生したため、安直にFirefoxの不具合だと疑ってしまいました。 通行人さんからのアドバイスを参考に、ATOKインサイトを無効にし、常駐させていたFirefoxを必要なときのみ起動させ様子を見てみます。 |
作成者: | 偶然的通行人 [ 2016年10月11日(火) 08:30 ] |
記事の件名: | Re: 文字入力ができなくなる |
応答が遅くてすみません。 Катюша さんが書きました: ATOKは発売日である2016年2月から使用しており、Firefox 47.0.1までは文字が入力できなくなるということはなく、 Firefox 48.0.0以降に不具合が発生したため、 仰るような経過があったのなら、「ATOKインサイト」が影響している可能性についても、若干見方が変わってくると思います。 一例を挙げれば、Firefox 47.0 系から Firefox 48.0 系の変化で注目された事柄に、マルチプロセス機能が一定条件下で有効になったことが挙げられます。 すべての Firefox 48.0 ユーザーの環境でマルチプロセス機能が有効になるのではなく、ごく限られた条件を満たす環境でのみ有効になっていましたので、実際にマルチプロセスが有効になるユーザー環境は限定的でした。ですが、Firefox 49.0 では有効化条件が広げられています。 (参考)・最新版 Firefox : マルチプロセス化の対象範囲が拡大し、デスクトップ版および Android 版に新機能が追加されました | Mozilla Japan ブログ https://www.mozilla.jp/blog/entry/10558/ もし、Катюша さんの環境では Firefox 48.0 / 49.0 のマルチプロセス機能が有効になっていたとすると、それが何らかの影響を及ぼしているのかもしれません(現時点で断定はできませんが)。 例えば、従来のシングルプロセスで動く Firefox では問題ないが、マルチプロセスで動く Firefox と「ATOKインサイト」の組み合わせでは問題が起こるとか、そういう状況も考慮の範疇に入ってくるのではないでしょうか。 [ヘルプ] -> [トラブルシューティング情報] -> [アプリケーション基本情報] -> [マルチプロセスウィンドウ] の値が、[1/1 (*** 有効)] のようになっていたら、マルチプロセス機能が働いています。[0/1 (*** 無効)] であれば、マルチプロセス機能は無効化されています(47.0 以前と同等)。 一度、このあたりを確認なさってはいかがでしょう。 その上で、OS 標準の Microsoft IME では同症状が発生するのかどうかを比較したほうが、ATOK 固有の問題かどうかを切り分けられそうに思います。 Microsoft IME でも同じ症状が発生するのなら、根は深いように思われます。 ATOK でのみ発生するのなら、ATOK 固有の何かが影響していると推測でき、そのひとつとしてブラウザに関与する可能性が高い「ATOKインサイト」の影響が考えられますが、これも現時点で断定できるわけではありません。 一方、本症状に対する Firefox の関わりについてですが、 Катюша さんが書きました: 常駐させていたFirefoxを必要なときのみ起動させ様子を見てみます。 といったテスト運用は、問題点の切り分けに役立つと思います。 OS の起動時に Firefox を自動的にスタートアップさせ、その際ホームページを表示させるとか、前回終了時のタブを復元しているような場合は、起動直後から ATOK の機能との関わりが生じると考えられますから、一時的にこうした運用を避けて使ってみることで、症状の変化を観察できるからです。 とりあえず補足まで。 (以下、余談) Катюша さんが書きました: Firefoxを終了すると直ちに回復する Катюша さんが書きました: ATOKは発売日である2016年2月から使用しており、Firefox 47.0.1までは文字が入力できなくなるということはなく、 Firefox 48.0.0以降に不具合が発生したため、安直にFirefoxの不具合だと疑ってしまいました。 このような状況なら Firefox の不具合を疑うのは当然ですし、いまも Firefox が無罪放免ということではありません。 しかし、文字入力は Firefox 単体で完結する動作ではないので、日本語入力システムなどの関連する要素にも、きちんと目を向けたほうがいいという意味で前便の話を書きました。 Firefox 上のメニューボタンを押しても反応しないなどの問題なら、Firefox 内部(アドオン含む)で完結した問題だと考えられますが、ある Web ページが正常に表示できないようなケースでは、Firefox に問題がある場合とサイト側に問題がある場合、さらには両者の特殊な組み合わせによる場合があります。 起こっている症状によってはそれを取り巻く条件が異なります。目についた点だけを先入観で見てしまったら本当の原因を見つけられず、したがって解決も遠ざかることがあります。 正常・異常を明確に判断できない状況では、関連する要素をすべて視野に入れた上で、手がかりのあるところから順序立てて問題点の切り分けをおこなうことが望ましいと思います。(そうした経過の中で、まったく別のところに原因が見つかることもあります。) とはいえ一度にあれもこれもはできませんから、日本語入力システムの角度から、Firefox の角度からという具合に要素ごとに比較・点検を進め、問題の所在を絞り込めてきたら、そこに注力していけばいいと思います。 このフォーラムのようなユーザーコミュニティーの利点のひとつは、多様なユーザーの知識や経験にもとづいて、多角的なアドバイスが寄せられることにあります。 |
作成者: | Катюша [ 2016年10月30日(日) 09:40 ] |
記事の件名: | Re: 文字入力ができなくなる |
途中報告です。 アドバイスを参考に2週間必要な時以外Firefoxを起動させない運用をしてきましたが、 この2週間は文字が入力ができなくなるという不具合は発生しませんでした。 なお、当方の環境ではFirefoxはシングルプロセスモードで動作しているようです。 今後はFirefoxを起動させたまま、MS-IMEに替えて様子をみることにします。 |
作成者: | WADA [ 2016年10月30日(日) 19:34 ] |
記事の件名: | Re: 文字入力ができなくなる |
Катюша さんが書きました: Excelやメモ帳上でカーソルが点滅している状態で文字入力ができず、その状態でスクリーンキーボードからは文字入力ができるので、 ご紹介いただいた事象とは異なる事象が発生しているようです。 何かが影響を与えているのでしょうが、現時点でわかっているのは 突然文字入力ができなくなるという不具合発生時に、Firefoxを閉じると問題は即時に解決し、 再度Firefoxを起動してもしばらくは文字入力ができるというところです。 カーソルが点滅していている、ということで、Firefoxへのフォーカスの移動は無関係だと思っていましたが、 Firefoxのバグのテスト中に以下のような現象をみたのと、キーボードフォーカスとマウスのフォーカスは独立しているので、ちょっと書いておきます。 長いですが、一言でいうと、「カーソルが点滅しているからといって、必ずしもそこに今Keyboard Focusがあるわけではない」ということの実証実験です。 (1) 以前から、WinのFirefoxには(ThunderbirdもSeaMonkeyも)、以下の問題があって、今もそうである。 WM_WINDOWPOSCHANGEDを受け取った時に、 本来は、最小化(または最大化)⇒元に戻す、の時にだけ出すべきSetFocusを、 最小化・最大化されてノーマルに戻ったFirefoxのウィンドウは、常にSetFocusを出してしまう。 (2) Win10になって、アクセントカラーやテーマが変わった時に、全てのウィンドウに対して、 WM_WINDOWPOSCHANGEDを送るようになったようである。 (Win8.1までは、このイベントでは送らなかったか、アクティブウィンドウにだけ、と思われる) (3) (2)のために、(1)の問題が表面化し、Win10でアクセントカラーやテーマが変わった時に、 Bug 1234317/Bug 1258152 の現象が起こるようになった。 (Firefoxの複数のウィンドウ、Thunderbirdの複数のウィンドウ、SeaMonkeyの複数のウィンドウ、の順番が変わってしまう) (4) (2)の影響は、Mozillaファミリーだけでなく、Win10における、MS Windowsのコンポーネントにも見られる。 いま明確なのは、以下の現象です。 File Explorerの、右側のファイル一覧の部分で、 縦・横スクロールバーのスクロール位置が、上端・左端ではない時に、 アクセントカラーやテーマが変わると、 縦・横スクロールバーのスクロール位置がリセットされて、上端・左端になる。 選択されたディレクトリーやファイルは、変わらない。 これは、File Explorerの状態(最大化、最小化、ノーマル)に関係なく起こり、 複数のノーマルウィンドウ(複数のアプリの複数のtoplevelウィンドウ)がある時の、 File Explorerのウィンドウの位置にも関係なく起こる。 (最小化されていてもWM_WINDOWPOSCHANGEDが送られている可能性がある。) (テーマ・カラー変更のメッセージによるかもしれないが、それならWin7/8.1でも起こりそう。) これらがあるので、以下のような現象を簡単に確認できます。 (a) Win10で、個人用設定で、以下の設定にしておく。 (a-1) 背景:スライドショー、間隔=1分 (a-2) 色:[ x ] 背景から自動でアクセントカラーを選ぶ、にチェックする。 (b) Firefoxを起動し、一度最小化し、タスクバーから元に戻す。 www.google.comを表示し、入力フィールドが常に見えるようにしておき、 入力フィールドをクリックして、カーソルを点滅させる。 (c) File Explorerを立ち上げ、ファイル一覧でディレクトリーが選択された状態にし、 ファイル一覧の部分のスクロール位置を、上端・左端から変えて置く。 (d) この時点では、File Explorer⇒Firefoxの順で、File Explorerが、最前面/アクティブ。 www.google.comの入力フィールドのカーソル・カーソルの点滅は無くなる。 (e) (a-1)によって背景イメージが変わると、(a-2)によってアクセントカラーが変わり、 (e-1) File Explorerでは、(4)の現象が起こり、スクロール位置がリセットされる。 (e-2) Firefoxでは、(1)が起こり、SetFocusが出される。 SetFocusだけではアクティブウィンドウの切り替えは起こらないので、 ウィンドウの順番などは変わらない。 しかし、www.google.comの入力フィールドで、カーソルのブリンクが起こる。 (カーソルブリンクは、必ずしもそこに今Keyboard Focusがあることを意味しない) (f) この時点で、最前面・アクティブウィンドウはFile Explorerなので、 Keyboard FocusはFile Explorerにあり、 Enterキーを押せば、(c)で選択してあったディレクトリーが開かれる。 また、ファイル名の変更をする時には、そこでカーソルブリンクして入力できるが、 後ろにあるFirefoxのwww.google.comのページでも、カーソルブリンクは継続している。 (カーソルブリンクは、必ずしもそこに今Keyboard Focusがあることを意味しない) 上記は、Win10でアクセントカラーが変わった時にWM_WINDOWPOSCHANGEDが送られた時の現象ですが、 WM_WINDOWPOSCHANGEDは、Size、Position、Z-Orderが変わったというイベントであり、 そのようなイベントが発生した時には、当然MS Winによって送られます。 Size/Positionの変更の時には、同時にマウスクリックイベントなどがあって、普通はそのウィンドウが最前面/アクティブになりますから、(1)によるフォーカス関連の問題は、ほぼ起こり得ません。 しかし、Z-Orderが変わっただけ、というイベントによって、WM_WINDOWPOSCHANGEDが送られた場合には、 Firefoxの一度最小化・最大化されたウィンドウは(Thunderbird/SeaMonkeyでも)、必ず(1)によるSetFocusを出すので、フォーカス関連の問題が起こる可能性があります。 最前面/アクティブウィンドウやウィンドウの順番は変わらなくても、(1)のせいで、FirefoxがSetFocusをだすので、内部的にはFocusが行ったり来たりします。 この時、IMEから見れば、突然Focusが奪われたり戻ったりするわけで、何かが起こる可能性があります。 単純にフォーカスが奪われるというだけではない、という現象で知られているものに、Dragが途中で消滅する、というものがあります。 これにはいくつかバリエーションがあるようで、フォーカスを途中で奪う犯人だと思われるものが見えている場合もあれば、どこでどうやってフォーカスが奪われるのか皆目見当がつかないものもあります。 Bug 948082 , Bug 1001549 , Bug 1022443 , Bug 1023620 などが、この系統のものです。 また、ThunderbirdだけでなくFirefoxでも同じようなことが起こるので、Coreの問題が関係していると考えられています。 Drag関連もFocus関連も、必ずしもWindowsだけの現象ではないので、全てが(1)によるものでは無いことは確かですが、 Winでの現象であって、Firefoxが関係しそうであることですし、(1)の問題は常に存在しますから、 (1)による影響は排除しておいた方がいいかもしれません。 Firefoxを立ち上げて様子を見る場合には、以下を組み合わせてみる。 (α)個人用設定でデスクトップのスライドショーを使っている場合には、 (α-1)色:[ x ] 背景から自動でアクセントカラーを選ぶ、のチェックをはずし、 不要なWM_WINDOWPOSCHANGEDの発生を極力避ける。 (α-2)あるいは、チェックしたままで、スライドショーの間隔を1分にして様子を見る。 (β-1)と組み合わせると、1分ごとにFirefoxにSetFocusをださせることができます。 (β)Firefoxの立ち上げ方を変えてみる。 (β-1)最低一回は、最小化してタスクバーから戻すか、最大化して戻す(1は起こる) (β-2)最小化も最大化も一度もせずに、立ち上げたままにする(1は起こらない) (β-3)最小化・最大化をして戻した後、最小化または最大化しておく。 (最小化・最大化されているとSetFocusはださないので、1は起こらない) ご参考までに。 |
ページ 1 / 1 | All times are UTC + 9 hours |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |