IE8のwindow.openの挙動について
-
2009年1月16日 4:08
window.open()で別ウインドウを開いた際にIE7では同一プロセス、IE8では別プロセスになるように
このフォーラム内でも議論されているようですが、IE8からは例外なくこのような仕様になるのでしょうか。window.open()で開いたウインドウについても元のウインドウのセッション（セッションcookieにて）を共有させたいと
考えているのですが、プロセスが別になるということは、セッションcookieの共有が出来ないように思えます。現在 IE8 beta2 を使用しておりますが、window.open()で開いたウインドウでセッション切れが発生し対応に苦慮しています。
アプリ側での解決策、もしくはブラウザの設定での解決策あればご指南いただけないでしょうか。
OS: WindowsXP SP3
ブラウザ: IE8 beta2
回答
-
2009年3月25日 2:07
お世話になっております。
先日リリースされました製品版にて、不具合が直っていることを確認できました。- 回答としてマーク まりもっこりーず 2009年3月25日 2:07
すべての返信
-
2009年1月16日 6:43
情報までですがご参考になれば。
セッションのマージング、フレームのマージングについては以下のレジストリで変更できるようです。
フレームのマージングについては Partner Build Updateで確認した際には動作していました。
キー名：
HKCU\Software\Microsoft\Internet Explorer\Main
エントリ：
FrameMerging
SessionMerging
データ型：
REG_DWORD
値：
1 (有効：既定）, 0 (無効）
です。ただ、このレジストリ値については、Beta2では動作していなかったようなことが以下に書いてありました。Partner Build Update ( その前に出ていた Partner Build は未確認）を使う必要がありそうです。
-
2009年1月22日 1:08
ありがとうございます。
返信が遅れまして申し訳ありません。
当方ではPartner Buildが入手できないため、Beta2にてエントリを作成し試してみましたが、
やはり、新しいウィンドウにセッションが引き継がれませんでした。
正式版でもセッションが引き継がれない挙動がデフォルトとなる場合、アプリへの影響が大きくなりそうです。
-
2009年2月13日 2:23私もアプリの検証で IE8 Beta2利用時に同様の現象が出ました。
いろいろ試したところ、
「ツール」-「インターネットオプション」-「全般」-「タブ」-「設定」にて、
何でもよいので一度設定を変更しブラウザを再起動することでこの現象が解消されました。
（元の設定に戻しても、現象は解消されている状態でした）
このような動作から、IE8のバグっぽい印象を受けるので
「仕様」でないことを祈ります。
（アプリでは解消できそうにないので。。。） -
2009年2月13日 5:36
こんにちは。五寳です。
IE8 から実装された LCIE (Loosely-Coupled IE) という機能によって、IE は基本的にタイミングによって別プロセスにてウィンドウ・タブが起動します。
これによって、ひとつのタブが落ちても、他のタブは影響を受けない、となっているのですが、Beta2 まではセッションレスなアプリケーションで問題が多かったのは事実です。
しかし Beta2 までは、HTTP Server/Proxy 認証のセッションは共有されませんでしたが、RC1 からはすべてのプロセス間で、ユーザーが明示的に別セッションで IE を立ち上げない限りプロセス間でセッションが共有されるようになっています。
明示的に別セッションで IE を立ち上げるには、メニューのファイル - 新規セッション で開くか、iexplor.exe を - nomerge をつけて立ち上げるか？になります。また、過去の IE と同じようにすべて同じ１つのプロセスで IE を使いたい場合は、下記のレジストリを設定していただくことで LCIE を無効にできます。
HKLM (or LKCU) \ Software\Microsoft\Internet Explorer\Main\TabProcGrowth- DWORD : TabProcGrowth
- 値 : 1 (値に 2 以上を入れると、従来のプロセス分離となります。0 は保護モードが有効な状態では有効な値になりません。)
五寳
-
2009年2月13日 13:03
お世話になっております。
ご回答ありがとうございました。
RC1になり、セッションが共有されることを確認いたしました。
しかし、当方で確認したところ、場合によっては、セッションの共有に不具合が発生するように見受けられます。
1. 「/a/b/c/X/XA」を表示。サーバより「Set-Cookie: JSESSIONID=sessionX; Path=/a/b/c/X; Secure」を返却。
2. 「/a/b/c/Y/YA」を表示。サーバより「Set-Cookie: JSESSIONID=sessionY; Path=/a/b/c/Y; Secure」を返却。
3. 「/a/b/c/X/XA」を表示。(ブラウザより JSESSIONID=sessionX を送信。)
4. 「/a/b/c/X/XB」を新規ウィンドで表示。(ブラウザより JSESSIONID=sessionX ではなく JSESSIONID=sessionY が送信されてしまう。)
以上のようにアクセスした場合、「4.」のタイミングにて、「1.」で設定した sessionX がブラウザから送信されず、
「2.」で設定した sessionY が送信されてしまいます。なお、「/a/b/c/X/...」と「/a/b/c/Y/...」は同一ドメインです。
パスごとに別のクッキーを設定しているにもかかわらず、正しく区別されず送信されているように見受けられます。なお、「4.」を同一ウィンドウで開く場合は正しいパスのクッキーが送信されることを確認しており、
新規ウィンドウで開いた場合のみの事象と思われます。
なお、「4.」 の「/a/b/c/X/XB」へのアクセスは、下記のようなJavaScriptにて、新規ウィンド(windowB)で開いています。
function openXB() { tgt = 'windowB'; w = window.open('', tgt, 'width=400,height=600,menubar=yes,toolbar=yes,location=yes,directories=no,status=yes,scrollbars=yes,resizable=yes'); form1.target = tgt; form1.submit(); } ～ 中略 ～ <form method="POST" action="/a/b/c/X/XB" name="form1" onSubmit="return false;"> <a href="#" onClick="JavaScript:openXB(); return false;">XBを表示</a> </form> -
2009年3月25日 2:07
お世話になっております。
先日リリースされました製品版にて、不具合が直っていることを確認できました。- 回答としてマーク まりもっこりーず 2009年3月25日 2:07
-
2009年3月26日 2:38はじめまして。
本スレッドと同様の問題があり、ここに辿り着きました。
製品版では確かに、「管理者権限」でログインしている場合には、同一サイトを別ウィンドウで開いた場合にも
Cookieが引き継がれているようですが、
「標準ユーザ権限」でログインしている場合には、別ウィンドウまたは別タブで開いた場合には、元ウィンドウで
発行されたCookie情報が引き継がれていないようで、ウィンドウを開いてもコンテンツが表示されませんでした。
Windows Vista SP1 + IE8正式版でのテストです。
この場合のCookieは、会員制サイトのID/PW認証済みであることを示すもので、コンテンツにアクセスする際
にCookieによる自動認証を必要とするものです。Cookieの内容はID/PWと有効期限などです。
リンク先のURLを取得して、元ウィンドウのアドレス欄に入力すればコンテンツを表示することはできますが、
そのコンテンツから新しいウィンドウを作った場合には、その内容は表示されません。
信用済みサイトに登録したり、ポップアップブロックを外したり、互換表示設定にしたりと、考えられる敷居を
すべて低くしましたがだめでした。
状況は、IE7以前でプライバシー設定の詳細で「自動Cookie処理を上書きする」で「ブロックする」になって
いるときと同じようです。
個人ユーザの場合には、基本的に管理者権限のまま使用していると思いますが、学校などの公共施設では
標準ユーザ権限にしている場合が多いので、大いに気になります。 -
2009年3月31日 11:34
まりもっこりーずさん、RTW 版での確認をありがとうございました。
返信しようと思っていましたが、遅れてしまいました。。。スミマセン。
ttomu さん、こんばんは。
Cookie の扱い方は、そのサイトによって様々です。 しかしながら、管理者権限でログインしている場合は、うまく Cookie が引き継がれるのに、標準ユーザー権限では引き継がれないとなると、その Cookie の最初の格納場所が管理者権限がないと読み込めないところにあるのだと思います。
別の話になってしまいますが、IE7 からある問題で、例えば信頼済みサイトにいれたサイトでは、基本的に保護モードがOFFになるため、そこで獲得した Cookie は中ILでアクセスできるフォルダに格納されます。
しかしながら、信頼済みサイトにない通常のサイトでは、IE は常に低IL で動作するため、中 IL で保存した Cookie は読み込むことができません。IE7 ではその逆である、中IL から低IL の Cookie も読み込めませんでしたが、それは IE8 で解消されました。(開発側の処理が必要ですが。。。)
一方、管理者権限で動作させている IE は高IL状態なので、どこに格納されていても Cookie を読み込めます。
ということで、可能性があるとすると、Cookie が格納されている場所が問題なのではないか？と思われます。
IE は通常低 IL で動作するため、低 IL の IE がアクセスできるところに保存されている必要があります。 その場合はクライアントでいくら設定を施しても、解決できません。
%homedrive%\users\%username%\AppData\LocalLow
(4/1 追加) Tempolary フォルダももちろん、Low アクセス対象です。
のような 低 IL でもアクセスできるところに保存されているかどうか、Web サイトオーナーに確認していただければと思います。
しかし、IE7 でうまくいっていたのならば、IE8 でも問題なさそうな感じがしますが。。。 -
2009年5月20日 6:46お世話になっております。
すみませんが、リリース版を使って、何回もやっていますけれども、別セッションになっておりました。
何の原因でしょうか？
若しかして、不具合まだ残しておいています。
宜しく -
2009年5月20日 16:24
参考までに、こちらで確認した内容を。
IE7かつ「cookie設定時にexpire指定なし」かつwindow.open時は、cookieは引き継がれる
IE7かつ「cookie設定時にexpire指定なし」かつ明示的に別プロセス起動時は、cookieは引き継がれない
IE7かつ「cookie設定時にexpire指定あり」かつwindow.open時は、cookieは引き継がれる
IE7かつ「cookie設定時にexpire指定あり」かつ明示的に別プロセス起動時は、cookieは引き継がれる
IE8かつ「cookie設定時にexpire指定なし」かつwindow.open時は、cookieは引き継がれる
IE8かつ「cookie設定時にexpire指定なし」かつ明示的に別プロセス起動時は、cookieは引き継がれる
IE8かつ「cookie設定時にexpire指定あり」かつwindow.open時は、cookieは引き継がれる
IE8かつ「cookie設定時にexpire指定あり」かつ明示的に別プロセス起動時は、cookieは引き継がれるIE7→IE8でexpire指定なし時のCookieが消える条件が変わっているため、
expire指定すれば問題ないのかなと思ったりしました。(それはそれで問題はあるかもしれませんが）
※IE8は製品版です
こちらではIE8で「標準ユーザ権限」でもCookieは引き継がれました。
.png){kind=spacer}
