Hebikuzure's Tech Memo

2012年1月30日

IE9 や IE10 でタブごとに IME の状態が分離される事について

Filed under: Internet Explorer — hebikuzure @ 8:10 PM

Internet Explorer 9 や Internet Explorer 10 ではタブごとに IME の状態が分離されており、一つのタブで変更したIME のモードは別のタブには引き継がれません。
これは以下のようにして確認する事ができます。

  1. 一つのタブを開いてそのページ内のフォーム(input type=”text” など)で IME をオン(ひらがなモードなどの日本語変換モード)にする
  2. 新しいタブを開き、同様にフォームのあるページに移動する
  3. 新しいタブのページ内のフォームにフォーカスする

この現象について、こちらのブログで Microsoft にフィードバックを行った結果について書かれています。このフィードバックに対して Microsoft の行った対処は、Windows 8 では IME の設定に “Let me set a different input language for each app window”(個々のアプリケーションのウィンドウごとに異なる IME の設定を許可する)という項目を追加し、IME の設定をログオン セッション全体で共通にできるようにする、という方法でした。
ただし前記のブログに書かれているように、この設定をオフにすると IE のタブ間で IME の状態が引き継がれるだけでなく、Windows で起動されているすべてのアプリケーションで IME の状態が共通になってしまいます。

(2011/1/31 追記:検証の結果、単純に LCIE だけが原因ではないと判明したので、以下の部分の説明は取り消します。)
どうしてこうなるのかと言えば、それは IE8 以降の Internet Explorer の動作モデルとして LCIE(Loosely-Coupled IE)が採用され、タブごとにプログラムのプロセスが分離されているからに他なりません。つまり IE9(や IE10)では、一つのウィンドウ内に複数のタブがあるので全体として一つのプログラムであるように見えますが、実際にはタブごとに同じ iexplore.exe(Internet Explorer の実行プログラム名)の別のプロセスが動作しているのであり、Windows 見れば同じプログラムが複数起動しているのと同じ状態になっています。そのため Windows 内で起動している個々のプログラムでは IME の状態も別々になるのと同じように、IE のタブ間でも IME の状態は別々になるのです。逆に、IE のタブ間で IME の状態を共通にしようと思うと、Windows 上のすべてのプログラムで IME の設定を共通にする必要がある訳です。

タブごとに iexplore.exe のプログラムが起動している様子は、タスク マネージャーの [プロセス] タブで観察できますし、さらに詳細には Process Explorer でも確認できます。

同じタブ ブラウザーでも Googel Chrome や Firefox、Opera ではこうした動作にはならず、同じウィンドウ内のタブ間では IME の状態は共通になります。これは Firefox や Opera ではタブごとにプロセスが分離されておらず全体で一つのプロセス(firefox.exe や opera.exe)となっており、Chrome ではタブごとに chrome.exe のプロセスが割り当てられるのですが LCIE のように分離が徹底されておらず、IME からは Chrome のウィンドウ全体に割り当てられている chrome.exe のプロセス一つが動作しているように見えるためです。(ここの説明はかなり簡略化しています)

(ここから 2011/1/31 追加)
このような動作となっている背景としては、IE8 以降の Internet Explorer の動作モデルとして LCIE(Loosely-Coupled IE)が採用され、タブごとにプログラムのプロセスが分離されている事があると思われます。IE9 (や IE10)では、一つのウィンドウ内に複数のタブがあるので全体として一つのプログラムであるように見えますが、実際にはタブごとに同じ iexplore.exe(Internet Explorer の実行プログラム名)の別のプロセスが動作しており、それを Internet Explorer 全体のウィンドウを管理しているプロセス(フレーム プロセスとも言います。これも実行ファイル名としては iexplore.exe)が束ねている形になります。そして IME の状態はそれぞれのタブのプロセスに紐づいているのではないかとの推測もできます。

タブごとに iexplore.exe のプログラムが起動している様子は、タスク マネージャーの [プロセス] タブで観察できますし、さらに詳細には Process Explorer でも確認できます。

このようなモデルにすると、一つのタブ内のページで深刻なエラー(例えばアドオンのクラッシュやスクリプトの無限ループ)が発生しても、そのタブのプロセスだけ再起動すればよく、他のタブやそこで開かれているページには影響を与えません。つまりブラウザー全体の動作を堅牢にし、エラー発生の際のユーザーへの影響を最小限にする事ができます。また再起動されたタブでもその影響を最小限にするため、タブで開いていたセッション情報(Cookie や一時ファイル、場合によってはフォームへの入力内容など)が復元されるよう、フレーム プロセスがそれぞれのタブのプロセスを監視し、必要な情報を保持しています。(Automatic Crash Recovery という機能です) タブごとの IME の状態についてはこの機能でも管理しているかもしれません。

そこで実験としてこちらのページに書かれている方法でタブ プロセスの分離を無効にし、タブ間での IME の挙動がどうなるか試してみました。その結果、TabProcGrowth 値を 0 にして Internet Explorer 9 のすべてのタブが一つの iexplore.exe で実行されるようにしても、タブ間で IME の状態は別々に保持されている事が確認できました。つまり各タブの IME の状態はタブごとのプロセスだけでなく IE のフレーム プロセスでも保持されており、タブ プロセスを分離しなくともタブごとに IME の状態が個別に保持される動作です。

なお同じタブ ブラウザーでも Googel Chrome や Firefox、Opera では Internet Explorer と異なり、同じウィンドウ内のタブ間では IME の状態は共通になります。これらのブラウザーでは個別のタブの情報として IME の状態を管理していないと思われます。

Windows 8 の “Let me set a different input language for each app window”(個々のアプリケーションのウィンドウごとに異なる IME の設定を許可する)という設定は、こうした個別のプログラムごとの IME の状態を無視し、Windows 全体(正確に言えば一つのログオン セッション全体)で一つだけの状態を共有するように強制する設定なのでしょう。
(ここまで 2011/1/31 追加)

タブごとに IME の状態が別々になるのか、共通になるのか、どちらの動作が好ましいのかについては議論があるでしょう。しかし Internet Explorer が目指している方向、もう少し広げて言うとモダン ブラウザーの志向を考えると、タブごとに IME の状態が別々に保持できる、今の IE の動作の方が良いのではないかと思います。ブラウザーは Web アプリケーションのプラットフォームである、という方向性を考えれば、ブラウザーのタブ一つ一つはそれぞれ別々の Web アプリケーションのフレームになります。そうすると、Windows 上の各アプリケーションのウィンドウごとに IME の状態が別々である方が良いのと同様、タブについても IME の状態は別々の方が良いでしょう。

具体的なシナリオで考えれば、次のように言えるでしょう。

  1. ブラウザーを起動して、SNS のサイト(Web アプリケーション)を開きます。ここでは投稿をしたいので IME を日本語入力モードにします
  2. 次に新しいタブでスプレッドシートの Web アプリケーション(例えば Excel Webapp や Google ドキュメントなど)を開いて、集計表にデータ入力をします。ここでは数値を連続して入力したいので、IME は英数入力モードにします
  3. さらに新しいタブを開き、ワードプロセッサのWeb アプリケーションを開きます。文書を作成するので IME を日本語入力モードにします

この状態で、SNS とスプレッドシートとワードプロセッサのタブを切り替えていく場合、IME の状態が共通になるのと別々に保持できるのと、どちらが使いやすいでしょうか。Windows 上の(ネイティブ)アプリケーションとの同一性という点からも、また実際の使い勝手からも、IME の状態が別々の方が便利であるのは明らかでしょう。

確かに一つの Internet Explorer のウィンドウ内で IME の状態が異なるのは、最初は若干の違和感があるかもしれません。またこうした動作は個々の好みもあるでしょうから一つの考え方を押しつけられたくない、という考え方ももちろんあるでしょう。ただ、上記のように今後のブラウザーの使われ方に沿って考えると、むしろ良い動作ではないかと思います。

(2011/1/31 追記) 個人的な感想としては、他のブラウザーとの操作感の共通化という視点も考え、「タブごと別々」/「タブ間共通」どちらの設定にもユーザーが任意に設定できると一番良いのではないかと思います。実装としては結構面倒ではないかとも思うので、やっぱりこれは難しいのかなあ。それと他のブラウザーも(前述のような理由で)IE と同じような動作になって行くのかもしれません。

皆さんのご意見があれば、ぜひコメントをください。

広告

2012年1月24日

Excel の数式バーを拡大する

Filed under: Microsoft Office — hebikuzure @ 9:08 PM


たいした話でもないのですが、何かの時に役立つかなあという覚書です。

Excel 関係のトレーニングなどで、Excel の画面をプロジェクタで表示してる際、数式バーに表示されている関数などの内容を見せたい時があります。ワークシートの内容であれば簡単に Excel の機能 (表示 –> ズーム) で拡大できますし、拡大鏡ツールや Zoomit などを使って画面自体を拡大表示する事もできますが、数式バー自体の表示を大きくして見せた方が分かりやすくスムーズに進める事ができる事もあるでしょう。

そこでちょっと確かめてみたところ、数式バーの表示 (表示するフォントのサイズ) は Excel のワークシート標準フォントのサイズと連動している事がわかりました。これを大きいサイズにすると、その分数式バーのサイズと表示フォント サイズが拡大します。Excel のワークシート標準フォントのサイズは Excel 2010 の場合、[ファイル] タブでバックステージ ビューに切り替え、[オプション] をクリック、[基本設定] の [新しいブックの作成時] セクションの [フォント サイズ] で変更できます。(Excel 2007 なら Office ボタン –> [Excel のオプション] から)

実際に標準のフォント サイズを 24pt にすると、数式バーはこんな風に表示されます。これなら数式バー内の関数などを説明しやすいでしょう。

image

ちなみにこの方法で標準フォント サイズを変更すると、新規に作成されるワークシートのフォント サイズも大きなサイズに変更されますが、以前に作成したブックを開く場合には何の影響もありません。必要な時だけ標準サイズを変更し、後で元に戻せば良いでしょう。

2012年1月22日

既定の整合性レベルとオートメーション

Filed under: Internet Explorer — hebikuzure @ 1:21 PM

Default Integrity Level and Automation
http://blogs.msdn.com/b/ieinternals/archive/2011/08/03/internet-explorer-automation-protected-mode-lcie-default-integrity-level-medium.aspx


一般のユーザーには馴染のないシナリオかもしれませんが、企業内アプリケーションなどでは、独自アプリケーションから Internet Explorer をオートメーションする事が良く行われます。こうした場合、Windows Vista + IE8 以上の環境では、Internet Explorer の保護モードと Loosely-Coupled IE の影響で、保護モード有効のセキュリティ ゾーン (例えばインターネット ゾーン) と保護モード無効のゾーン (例えばイントラネット ゾーン) を越えてページ遷移する場合、オートメーションの呼び出し側アプリケーションが、Internet Explorer への参照を失って制御できなくなる現象が起きます。これについて EricLaw’s IEInternals の解説記事を私訳しました。 (今回はコメントにも重要な情報が書かれているので、コメント部分まで訳しています)

Internet Explorer をオートメーションするような企業内アプリでは、ターゲットとなる Internet Explorer のバージョンが固定されている場合がまだ 一般的で、その多くは (特に日本国内では) IE6 を対象としているのではないかと思われますが、今後 Windows XP・IE6 のサポート切れに伴い新しいバージョンをターゲットに改修されるケースが増えてくると考えられます。そうした場合に IE6 ではなかったこうした挙動について理解し、記事に書かれているような適切な対処をする事が必要になります。

以下の文章は EricLaw’s IEInternals の 2011/8/3 の記事 Default Integrity Level and Automation を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation および日本マイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


既定の整合性レベルとオートメーション

EricLaw [MSFT]

2011年8月3日 9時42分

StackOverflow で、danimajo さんが興味深いシナリオについて助力を求める質問をされています。基本的には、彼は Internet Explorer をオートメーションを通じて操作しようと試みているのですが、イントラネットのサイトに遷移すると非表示のブラウザーのインスタンスがあらわれ、それを制御する事ができなくなるのです。いったい何が起きているのでしょう?

保護モードの背景にあるもの

Internet Explorer の保護モードは、Windows の整合性レベル システムに基づくセキュリティー サンドボックスです。一つのプロセスは一つだけの整合性レベル (IL) を持ちますから、IE のインスタンスがインターネット (保護モード、LowIL) とイントラネット (非保護モード、MediumIL) の間を遷移すると、Internet Explorer は遷移を新しいプロセスでハンドルする必要があります。Vista 上の IE7 では、この動作はよく見える形であらわれます—新しいブラウザー ウィンドウが自動的に開かれます。IE8 では、Loosely-Coupled IE (LCIE) の導入により、この動作はより微妙に取り扱われます。

Loosely-Coupled IE の背景にあるもの

LCIE では、常に少なくとも二つのプロセスが存在します—ブラウザーのフレーム マネージャー プロセス (IE を管理者として実行しない限り、常に MediumIL で動作します) とブラウザーのタブ コンテンツ プロセスで、後者は以下のように実行されます:

  • 保護モードのサイトでは LowIL
  • イントラネット/信頼済みサイトでは MediumIL
  • HighIL (IE が管理者として実行された場合)

フレーム マネージャー プロセスはどの整合性レベルのタブも “可視的に” ホストできますから、ユーザーが LowIL のゾーンから MediumIL のゾーンのページに遷移すると、フレーム マネージャー プロセスは現在のタブ プロセスを異なる整合性レベルで動作するタブ プロセスに、サイレントに置き換えます。この動作は “Virtual Tab switch” (仮想タブ切り替え) と呼ばれます。

制御を失う場合

多くのシナリオへの互換性のため、Internet Explorer は既定のタブ プロセスを整合性低のタブであるとみなしています。したがって Internet Explorer が COM オートメーションにより生成される際、タブ プロセスの既定は整合性低のタブになります。ブラウザーはページ遷移により整合性中のタブ コンテンツ プロセスが必要であると判断すると、仮想タブ切り替えが実行されます。ここに興味深い点があります—なぜなら Internet Explorer をオートメーション経由で制御しているスクリプトやコードがその際に使用されなくなるタブ プロセスへの参照を持っていると、制御を失うのです。

制御を再獲得する

さて、呼び出し側がこの状況をハンドルする事は可能で、NewProcess イベント をトラップして適切に対処すればよいのです。とは言え、これにはそれなりの量のコードが必要ですし、場合によっては (一例として、イントラネットのページにのみ遷移するように構成されている場合など) 望ましい物ではなく、オートメーションの呼び出し側アプリケーションが単に自身の必要に応じて権限昇格をしてはじめから MediumIL で動作する Internet Explorer のインスタンスを呼び出す方が良いかもしれません。C++ や C# のような言語ではこれは容易で、CLSID_InternetExplorerMedium ("{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}") のインスタンスを CoCreate するだけです。この CLSID を利用すれば、オブジェクトは既定で MediumIL タブ コンテンツのプロセスになります。この動作の仕組みはとても単純です: レジストリ キー HKEY_CLASSES_ROOT\CLSID\{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}\LocalServer32 には "%ProgramFiles(x86)%\Internet Explorer\iexplore.exe" –startmediumtab という REG_EXPAND_SZ 値が含まれています。

残念ながら、私が説明できる限りでは、VBScript や JavaScript ような CScript や WScript の下で動作しているスクリプト言語は、CLSDI を CreateObject に渡す方法はありません—これは ProgID のみ受け付けます。更新情報: WndSks さんが以下のコメントで示しているように、以下の構文が利用できます Set IE = GetObject("new:{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}")

CLSID_InternetExplorerMedium にマップされている ProgID はありませんが、単にレジストリを更新する事で簡単に作成できます。

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\InternetExplorer.ApplicationMedium]
[HKEY_CLASSES_ROOT\InternetExplorer.ApplicationMedium\CLSID]
@="{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}"

こうすれば、MediumIL インスタンスの IE をスクリプトから呼び出せるようになります:

Set IE = CreateObject("InternetExplorer.ApplicationMedium")
‘ IE.Visible = false ‘ This is the default
IE.Navigate2 “http://intranetpage/”

保護モード外で実行されるページのみこのインスタンスで遷移するようにすれば、皆さんのオートメーション コードは参照を失うことなく、Internet Explorer のウィンドウも特に visible プロパティーを変更しない限り可視状態のままになります。

-Eric


コメント

RichB
2011年8月3日 午前11時33分
GetObject() を clsid: モニカに渡せばうまくいくのでは?
msdn.microsoft.com/…/aa392394(v=vs.85).aspx

EricLaw [MSFT]
2011年8月3日 午前11時38分
@RichB: うまくいかないなあ。もっとも僕はスクリプティングのエキスパートとは程遠いから。

WndSks
2011年8月3日 午後2時39分
Set IE = GetObject("new:{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}")
IE.Visible = true

EricLaw [MSFT]
2011年8月3日 午後2時43分
ありがとう、@WndSks—あなたの構文は Win7 でちゃんと動きました。

danimajo
2011年8月3日 午後9時31分
Eric さんありがとう! この答えはすばらしく役に立ちました!

2012年1月9日

2011年の人気記事

Filed under: Information — hebikuzure @ 9:08 PM

2011年を通じてこのブログの記事で最も表示回数が多かったのは、2009年4月12日に投稿した「サーバー上の共有フォルダで Excel ファイルを上書き保存するとファイルが失われる 」でした。この記事の公開日は 2009年と古いのですが2010年もよく参照されており、2011年6月に追記をしたためもあって年間1位になったのかと思います。
さて、この記事の元ネタになっているマイクロソフト サポート技術情報 968102「Windows Server 2008 R2、Windows Server 2008、または Windows Server 2003 R2 で DFSR が有効に設定されている共有フォルダに Excel ファイルを上書き保存した場合にファイルが消失することがある」も参照数が多いのでしょうか?

2012年1月7日

Authenticode と弱い証明書チェーン

Filed under: Internet Explorer — hebikuzure @ 6:53 PM

Authenticode and Weak Certificate Chains 
http://blogs.msdn.com/b/ieinternals/archive/2011/08/20/internet-explorer-downloaded-file-was-reported-as-unsafe-by-winverifytrust-when-using-md2-or-md4.aspx


遅くなりましたが、あけましておめでとうございます。今年最初のポストです。
今回も EricLaw’s IEInternals の記事から役立ちそうな記事を私訳しました。 古いソフトウェア パッケージをダウンロードしてインストールや実行しようとする際に起きがちなトラブルについての解説です。Windows 7 SP1 以降の上の Internet Explorer 8 以降のブラウザーでは、証明書チェーン内で MD2 または MD4 アルゴリズムを利用した Authenticode 署名を受け入れないという点がポイントです。 

以下の文章は EricLaw’s IEInternals の 8/19 の記事 Authenticode and Weak Certificate Chains を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation および日本マイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


Authenticode と弱い証明書チェーン

EricLaw [MSFT]

2011年8月19日 午後4時28分

最近の事ですが、ある人が非推奨になっているバージョンの Windows Script debugger をダウンロードしようとしました。このツールは IE8 以降に含まれているような、より強力で現代的なツールが出現するまで、スクリプトのデバッグによく使われていました。このユーザーはその際の非常に驚くような結果について、私にメールで知らせてきました:

Run ボタンをクリックすると、ダウンロードは進行しますが、<filename> was reported as unsafe (<filename> は安全でないと報告されています) というメッセージが表示されました。

明白な疑問は、誰が、または何がこのファイルを安全でないと報告しているのか?” です。

多くの方が、それは SmartScreen の警告だと思われるでしょうが、そうではありません。SmartScreen は既知のマルウェアをブロックすると、以下のスクリーンショットのような表示を出します:

それではこれが SmartScreen ではないとして、では警告はどこからされているのでしょう?

答えは、<filename> was reported as unsafe (<filename> は安全でないと報告されています) というメッセージは WinVerifyTrust API がダウンロードしたファイルのデジタル署名に問題があると報告するために表示されているのです。非常に単純なことです。例えば、不完全なダウンロード ファイルを開こうとした場合にもこのエラーが表示されるでしょう。

ところが Windows エクスプローラーで署名を確認すると、何も問題がないように見えます:

詳しく見ると、署名には問題ないと上部に表示されていますし、下部に表示されているタイムスタンプも、この証明書の期限が切れても署名自体は有効であり続けます。とはいえ、このタイムスタンプは 12 年前のもの…これはとても古いファイルです。

そこで、View Certificate (証明書の表示) ボタンをクリックすると、皆さんが私のブログをよく読まれているのであれば、問題を指摘できるでしょう:

見ましたか?

問題は、証明書自身が署名に MD2 ハッシュ アルゴリズムを利用していた事でした。このアルゴリズムは脆弱である事が知られており、信頼されないコンテンツをセキュアでないネットワークを経由して送受信するためには安全でないのです。そのため、私がこのブログで何度かわたって指摘しているように、Windows 7 SP1 以降の上の Internet Explorer 8 以降のブラウザーでは、証明書チェーン内で MD2 または MD4 アルゴリズムを利用した Authenticode 署名を受け入れなくなりました。(root 自身の MD2 と MD4 については問題ありません。なぜならroot 自体はマシンにインストールされているからです) この制限は WinVerifyTrust の WTD_DISABLE_MD2_MD4 フラグによって制御されており、証明書チェーン内でそれらの弱いアルゴリズムが利用されている署名を拒否するよう指定しています。当分の間、Windows エクスプローラー自体はローカルにインストールされているファイルでの MD2 とMD4 の利用を認めます。これは今日の環境での脅威の多くは Web の利用によりもたらされるコードに起因するからです。

現実的には、推奨されないアルゴリズムを使用した署名のついたダウンロードは極めて珍しいという事が分かるでしょう。それは MD2 と MD4 が利用されていた 1990 年代の末期にソフトウェア パッケージを署名していたソフトウェア ベンダーは相対的に少数だったからです。私たちは Microsoft ダウンロード センターにある少数の古いインストーラは削除されるか、またはデジタル署名をごまかそうとする熟練した攻撃者に対するより強力な防御のために現行の証明書と新しいアルゴリズム (例えば SHA-1) で再署名する必要がある事を、認識しています。

-Eric

WordPress.com で無料サイトやブログを作成.

%d人のブロガーが「いいね」をつけました。