遅ればせですが、横から失礼します。
当方にも Windows 7 環境があるので、一番ロースペックな環境でざっくりテストしてみました。
OS = Windows 7 Home Premium SP1 (64bit)
Firefox 60.2.2 ESR (32bit)
Firefox 52.9.0 ESR (32bit)
CPU = Celeron 1000M 1.80GHz
RAM = 8.0GB
Graphic = Intel HD Graphics (無印)
（基本的な手順）Firefox が起動していて、フォームの select タグを持つページを開いた状態で、Windows を 待機状態（Ｓ）に移行し、約 3 分経過後に復帰させました。
テストパターンは４種類です。（グラフィックと待機状態の組み合わせ／等幅フォントで最適化）
────┬──────┬──────
Ｇ＼Ｓ │ スリープ │ 休止状態
────┼──────┼──────
Aero │ （１） │ （３）
────┼──────┼──────
Classic │ （２） │ （４）
（テスト結果）当方の環境における復帰後の挙動は、次の通りでした。
（A）Firefox 60.2.2 ESR の場合【スリープ】（１）（２）ともに、ご質問の中で挙げられている 4-1) 、4-2) 、4-3) のような症状はとくに起こらず、いずれの操作も普通に実行できました。
【休止状態】（３）（４）ともに、Firefox のウィンドウが表示された直後の早いタイミングでクリックしたときは、4-1) 、4-2) 、4-3) のような症状が起こることがありました。必要十分な時間を置き、完全な復帰後にクリックしたときは、すべて正常に反応しました。
f-angel-mzzj さんが書きました:
4-1)画面中にある普通のリンク・ボタンはクリックで遷移や動作ができるが、
プルダウンメニューの▼印をクリックしても反応しない。
f-angel-mzzj さんが書きました:
「進む」・「戻る」・「オプションを開く」などほかのボタンは反応する。
当方ではこのようなことはなく、反応しないときはこれらのボタン類を含めて Firefox 全体が無反応でした。
とくに、完全に復帰していないと思われる状態で無理に 4-1) 、4-2) を連打すると、高確率で Firefox がハングアップしました。
（３）（４）を比較した場合、（３）のほうが全体的なレスポンスはよく、「プルダウンメニューの▼印をクリックしても反応しない」に遭遇したあと少し時間を置いて再度クリックしたときは、正常な動作をしてくれました。
（B）Firefox 52.9.0 ESR の場合【スリープ】
（A）と同様でした。
【休止状態】基本的には
（A）と同様でしたが、若干の違いは感じられました。
Firefox 60.2.2 ESR と比べた場合、52.9.0 ESR のほうが（３）（４）において完全復帰までの時間が短いという印象です。（厳密な計測はしていませんが体感的に...。）
（考察）上述のようなロースペックな環境下でも、完全な復帰後であれば、すべてのパターンにおいて Firefox 60.2.2 ESR と 52.9.0 ESR のどちらも問題なく動作した点に注目します。
（B）の結果からは、ユーザー環境（とくにハードウェアスペック）と復帰後の操作タイミングによっては、Firefox 60.2.2 ESR と 52.9.0 ESR で問題の起こり方に差が出ることは十分ありえるのでは、という印象を持ちました。
（４）では完全復帰までの時間が体感できるほどに長かったのですが、これを単純に Firefox 60.2.2 ESR の「不具合」と結論することには疑問が残ります。なぜなら、復帰の動作は Windows が制御しているからです。両者を視野に入れ順序立てて考えないといけない気がします。
ご存知のように、「スリープ」と「休止状態」は似たような待機状態を作り出しますが、その仕組みは違います。
機能の名称
＿＿データ保持
＿＿電力消費
スリープ
＿＿＿メモリー上
＿＿あり
休止状態
＿＿＿ドライブ上
＿＿なし
「スリープ」の復帰がメモリー上のデータを復元するのと比べ、「休止状態」からの復帰は、ドライブに退避したデータをメモリーに読み込んで再構成する分、それなりの時間がかかります。
「休止状態」へ移行する前の稼働状況、ハードウェアスペックと OS 、ドライバー類の諸条件に左右されると思いますが、復帰後アプリケーションソフトのメインウィンドウが表示されても、休止前の OS やアプリケーションの状態がまだ完全に復元されていないタイミングで操作をしたときは、正常な反応を返さない場面に遭遇することが多くなると思います。もちろん、ハードウェアスペックが高いほど遭遇確率は減ると思いますが...。
技術的な詳細までは知りませんが、Aero 環境では CPU だけでなく GPU の能力を積極的に活用した描画処理がおこなわれており、Classic 環境では従来のように CPU のみに依存した描画処理がおこなわれていたと思います。
Firefox 側の動作も、OS やハードウェアの影響を受けます。積極的に GPU を利用「できる／する」ことを前提にしているときと、CPU にのみ依存したときとでは、違いがあるのかもしれません。
すでに EarlgreyTea さんがご説明なさっているように、Firefox のバージョンが新しいほど、最新の OS やハードウェアの機能に最適化するよう調整されているので、古めの OS で稼働はしても、パフォーマンス的には実力を発揮しきれないケースはあると思います。
f-angel-mzzj さんが書きました:
以上の状態はアドオンを組み込んだ当方の通常運用環境だけでなく、
セーフモードや新規プロファイルでも発生することを確認しています。
これを、そのまま Firefox 本体の普遍的な不具合と結論づけるか、Firefox 側の動作条件に左右されない要因が潜んでいる可能性に目を向けるかで、その後の対処方針が変わってくるように思います。
本件の場合、再現条件として OS の待機状態の動作を前提に含んでいるため、後者に重点を置いて検証しないと本当のことは見えてこないのではないか、と思います。
f-angel-mzzj さんが書きました:
マルチプロセスの有無で挙動が変化するのはどう解釈すべきでしょう？
シングルプロセスに比べ、待機状態からの復帰プロセスが複雑になる分、完全な復帰状態に至るまでの時間が長くなっているんじゃないでしょうか。
f-angel-mzzj さんのところで起こっている症状を上述のような条件下では再現できましたが、待機状態から完全に復帰したタイミングであれば、当方の Firefox 60.2.2 ESR / 52.9.0 ESR は（１）～（４）すべてのテスト条件下で普通に動作してくれました。なので、本質的に回避不能な不具合とは思えませんでした。
この点から考えるなら、ご質問の症状は、ハードウェアを含むユーザー環境の条件と復帰後の操作タイミングの組み合わせで起こっている、という見方もできるのではないでしょうか。
もっとも、ぼくのテスト環境と f-angel-mzzj さんの環境が同じだとは限りません。違いがあれば、結果が異なることもあるでしょう。
この先さらに調べれば明らかになる事柄が出てくるかもしれませんが、現時点の既出情報から導かれる判断としては、ぼくも EarlgreyTea さんや maji さんと同意見です。
簡単なテストと考察にすぎませんが以上です。的外れな話だったらすみません。
（おことわり）
現在、健康上の制約により不定期な書き込みしかできなくなっています。すぐに応答できない場面がかなり多くなりますことを、ご容赦ください。
ログイン
ユーザー登録
FAQ
検索
