none
IE8において別サーバの親子ウィンドウにてwindow.opener.location.hrefが新規ウィンドウとして認識される。 RRS feed

  • 質問

  • IE8(Internet Explorer8) において、

    javascript window.opener.location.href 」の動作が

    IE7 Firefox3.6 と異なる仕様になったのか、思い通りの動作をしてくれません。

     

    JavaScript の仕様が変わったのか、 IE の仕様が変わったのかわかりませんが、

    詳しい方がいましたら知恵を貸して頂けると幸いです。

     

    【構成】

    ウィンドウの遷移とサーバの関係は以下のとおりとなっています。

    親サーバと子サーバは完全に別物です。

     

    ①親ウィンドウ、起動画面の URL (親サーバ):

    https://hogehoge/test/index.do

             newWin = window.open('about:blank','_subWin','width=800,height=840');

            newWin.focus();

     

    ②子ウィンドウ ( ポップアップ ) URL (子サーバ):

    http://children. hogehoge /jsp/index.do

            window.blur();

            window.opener.focus;

            window.opener.location.href = "https://hogehoge/test/result.do?nowAge=" + age;

     

    ③親ウィンドウ、結果画面の URL (親サーバ):

    https://hogehoge/test/result.do

     

    【想定している手順】

    1.親ウィンドウ①から、 window.open() を使って子ウィンドウ②を開く

    2.子ウィンドウ②で一連の動作を完了後、ボタンをクリックすると

    親ウィンドウ①を window.opener.location.href で指定したページ③へ切り替える

     

    このような動作を行うと、 IE7 Firefox3.6 では元々開いていた

    親ウィンドウ①の URL が③に切り替わります。

    しかし、 IE8 にしてからは、もともと開いている親ウィンドウ①は変化なく、

    新たに別ウィンドウ(ポップアップウィンドウ)が開き、そこに③が表示されてしまいました。

    (ポップアップブロックの警告が出るので一時的に許可などすると新規ウィンドウを表示してしまう。)

    IE7 はポップアップとはならずに正常に画面遷移する。

     

    他に試したこととしては、

    ・子ウィンドウを Firebug で調べたところ window.opener の値は取れませんでした。

    ・親ウィンドウも子ウィンドウも Firebug name 確認とれましたので、

    target で指定するやり方も試しましたが、その場合 FireFox でも新規ウィンドウを開く形になってしまいました。

     

    セッションがウィンドウ間で繋がっていないのでしょうか?

     

     

    JavaScript を修正するなどして、

    IE8 で従来と同じように動作させることは可能でしょうか?

    よろしくお願い致します。

     

    ――――――――――――――――――――――

    なおこの投稿をする際、以下のページを参考にさせて頂きました。

    (未解決ですが、こちらの環境とかなり近いです)

    IE8 window.opener.location.href 動作について

    http://questionbox.jp.msn.com/qa4960388.html

    2010年10月1日 3:24

すべての返信

  • 再現しました。(`・ω・´)

    こちらでも、IE7やFF3.6では別ウィンドウになりませんが、IE8では別ウィンドウになりました。

    【事象確認】
    親ウィンドウと子ウィンドウでは

    ・プロトコル(スキーム)
    ・ドメイン(サブドメイン部)
    ・もしかしたらセキュリティゾーンも(ホスト名が「hogehoge」という風に「.」(ドット)が付与されていないため)

    上記が異なるのですね。

    要望としては、この状態で、httpで表示した子ウィンドウを操作することによって、httpsで表示している親ウィンドウのURLを操作したい。
    現在はJSでlocation.hrefを操作することによって実現しているが、IE8ではポップアップしてしまう。
    ポップアップとならないようにしたい。
    プロトコルやドメインが一致すればポップアップとならないことは私の方でも確認しましたが、その辺は変えないことが前提ですということですね。

    上記から、条件はsame originかどうかと推測されますが、
    ブラウザ(IE)が実現したいことと、recalさんが実現したいことは異なる可能性があるため、それを見つける必要がありそうですね。

    【回避案の模索】
    ・ダメ案1:Emulate=IE7を付与してみる。
    →IE8でもIE8と同様の動作となってしまった。

    ・ダメ案2:
    いけそうな案としては、親ウィンドウでサーバ側のフラグをポーリング&子ウィンドウではJSONPなどでフラグ書き換えですが、、、それはないでしょうね。

    ・ダメ案3:document.domainを設定することででどこまでがsame originかを定義してみる
    →サブドメイン部だけが異なるのであれば、この方法でポップアップとなっていたものがポップアップにならないのは確認済みですが、
    スキーム(httpかhttpsか)も異なる場合は、ポップアップとなってしまいました。ここをどうにか出来ればよいのですが、ちょっとなさそうです。
    http://www.w3.org/TR/html5/origin-0.html#effective-script-origin

    【どこかにヒントが埋もれていないか】
    FF3.7bのソースコード(nsLocation.cpp)を確認してみましたが、当然ながらIE8でポップアップとなってしまう回避手段は見つけられそうにありませんでした。

    【前提となるブラウザの動作について】
    以下を試しました。
    全て、httpで表示した子ウィンドウから、httpsで表示している親ウィンドウに対する操作です。

      XP&IE7 XP&IE8 Win7&IE9b FF3.6 Chrome6
    親で定義されたメソッドの参照
    「window.opener.method1」
    ×1 ×1 ×1 ×3 ×4
    親で定義されたメソッドの呼び出し
    「window.opener.method1()」
    ×1 ×1 ×1 ×3 ×4
    location.hrefの参照
    「window.opener.location.href」
    ×1 ×1 ×1 ×3 ×4
    location.hrefの書き込み
    「window.opener.location.href = "xxx"」
    ○ ※1 ○ ※1
    location.replaceまたはlocation.assignの参照
    「window.opener.location.replace」
    ×1 ×1 ×1 ×3
    location.replaceまたはlocation.assignの呼び出し
    「window.opener.location.replace("xxx")」
    ×1 ×1 ×1 ×3
    document.locationの参照
    「window.opener.document.body」
    ×2 ×2 ×2 ×3 ×4
    document.locationの書き込み
    「window.opener.document.location = "xxx"」
    ×2 ×2 ×2 ×3 ×4

    「×1」とは、「書き込みできません。」というWebページエラーのこと。(IE9のコンソールに出てくるエラー番号のようなものは、"SCRIPT70"です)
    「×2」とは、「アクセスが拒否されました。」というWebページエラーのこと。(SCRIPT5)
    「×3」とは、「Permission denied for<hogehoge>to get property Window.method1 from xxx」というWebページエラーのことを指しています。
    「×4」とは、「Unsafe JavaScript attempt to access frame(中略). Domains, protocols and ports must match」というエラーのこと。
    「○」とは、画面遷移したり、メソッド呼び出し時にランタイムエラーとならないという意味です。

    ※1:別ウィンドウが開いて指定されたURLが表示される。

    表の見方は、例えば、locationオブジェクトのhrefのsetterは動作しますが、getterはエラーでした。これはIE7でもIE8でもFireFox3.6でもChrome6でも同様です。
    どのブラウザでもドメインとプロトコルが一致すれば、正常に動作しました(「×」ではなく「○」になる)。

    また、同じ画面遷移を実現するための手段によって動作する・しないが変わっていることが分かりました。

    で、この方法で攻めても「プロトコルやドメインが一致すること」以外の条件はみあたらない感じですね。。

    2010年10月5日 17:30
  • (´・ω・`)さん

    動作確認およびご連絡ありがとうございます。

     

    >・もしかしたらセキュリティゾーンも(ホスト名が「hogehoge」という風に「.」(ドット)が付与されていないため)

    上記でおっしゃっている意味がわかりませんが、「hogehoge」の部分をもう少し詳しく書くと下記になります。

    親ウィンドウ:https://www.hogehoge.jp/test/index.do

    子ウィンドウ: http://children. hogehoge.jp /jsp/index.do

     

    > プロトコルやドメインが一致すればポップアップとならないことは私の方でも確認しましたが、その辺は変えないことが前提ですということですね。

    そうですね。プロトコルもドメインも変えないのが前提ですね。

     

    >で、この方法で攻めても「プロトコルやドメインが一致すること」以外の条件はみあたらない感じですね。。

    やはり、プロトコルとドメインが一致しない場合は難しそうですね。

    上記現象は他でも良く発生しそうなのですが、あまり情報が出てないみたいですね。

     

    クロスドメインアクセスについてはまだ勉強不足のため、勉強してみたいと思います。

     

    また何かありましたら、ご連絡いただけると助かります。

    2010年10月6日 1:54
  • >上記でおっしゃっている意味がわかりませんが、「hogehoge」の部分をもう少し詳しく書くと下記になります。
    どうもです。これは以下の話でした(原因欄)。どうやら両方ともドット付きなので、どちらもインターネットゾーンとのことですね。
    http://support.microsoft.com/kb/303650/ja

    >上記現象は他でも良く発生しそうなのですが、
    私も良く発生しそうだと思っています。なので、少し詳細なレスをさせていただきました。
    なお、表が表っぽく表示されていなかったのを修正を行いました。

    >クロスドメインアクセスについては
    私は、今回のケースそのものがIE7→IE8で行いたかったことではなく、結果としてクロスドメインが条件(の一部)となって表れたと考えています。たとえクロスドメインだったとしてもやってよいこと、よくないこと、その中間的なものが存在するのかなと考えています。
    ある意味、誤爆だと考えています。
    もちろん、爆風の範囲は事前に十分検討調査されたものでしょうが、今回のケースのみピンポイントで検討した場合に、どうかなと思う部分があります。

    最近クロスドメインを制御するための仕組みがいくつか増えていますが、私のほうではこの問題を回避するための手段は見つけられていません。
    もっと画期的な方法が見つかればよいのですが。何か見つかりましたらご教授いただけると幸いです。

    >また何かありましたら
    保護モードの有無とLCIE(TabProcGrowth)は今回の件には影響しないようです。

    2010年10月6日 8:07
  • (´・ω・`)さん

    >保護モードの有無とLCIE(TabProcGrowth)は今回の件には影響しないようです。

    なるほど。ありがとうございます。

     

    こちらでもいろいろ試したり調べたりはしているのですが、

    どうもダメみたいです。

    ただ、(´・ω・`)さんがIE9bで試していただいている結果をみると再現してますので、

    IE8のバグというよりもIE8からの仕様ということになるのでしょうかね。

    今後影響が広がりそうです。。。

    2010年10月6日 9:13
  • この件ですが、

    Internet Explorer Compatibility Test Toolというツールを使用することで、
    IE内でどのようなセキュリティに引っ掛かったかのログを見ることが出来ることが分かりました。

    ※互換性の確認ツールとありますが、イベントリストを見る限り、実際はセキュリティ問題の確認ツールといった印象を受けています。

    確認してみると、次のログが出力されました。

    概要として、セキュリティ コンテキストが異なる別の Web サイトへは既存のフレームに移動先ページが表示される代わりに、新しいウィンドウまたはタブが開きます。とあります。

    上記リンク先に書かれている理由の”HTML 5 草案のウィンドウの移動に関する規定”とは
    http://www.w3.org/TR/html5/browsers.html#security-nav
    のことかなと思っています。

    フレーム→別ウィンドウ
    ホスト名→ホスト名とポート番号とプロトコル
    と若干リンク先に書かれてある条件が狭いですが、セキュリティ コンテキストが異なる条件は他にもデバッガ経由で起動(@see IE8とtarget frame)かどうかもあると思っているので、そこについては深くここでは触れられていないようです。

    対策として、確認済みでしょうが、postMessageが使えるのではないかと思っています。(未確認)
    2011年2月4日 23:50