Bisect:
441894 (good) - 441896 (bad), 57.0.2974.0
https://chromium.googlesource.com/chromium/src/+log/950a485a..40458d4d?pretty=fuller
Suspecting r441896 "Remove ScriptController::initializeMainWorld"

Bisect range :
You are probably looking for a change made after 441895 (known good), but no lat
er than 441896 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/3898922f0e5f70f0cbd8a7edbc6d7001b0d60ec5..40458d4dd913d5fd6f4f1bb2da083a8a7136a9af


Thank you  woxxom@

The bisect range does makes sense. In the example I gave above, If there is a "script" tag (even if empty as in "<script></script">) added in the html output of the child window it does seem to work. It is only if the child window has no "script" tag.

@haraken: Gentle ping, request you to please take a look into it. Issue is tagged with a Stable blocker label and M57 milestone. M57 is set to be pushed to stable soon. 

dominicc@: Would you triage this in the DOM team?

Why do you think this is a DOM bug?

A friendly reminder that M57 Stable is launch is coming VERY soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch (2987) ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

(I'm now travelling. I'll take a look on next Monday, Feb 27.)

URGENT - PTAL ASAP.

We're getting VERY close to M57 Stable promotion. And 
this issue is marked as M57 stable release blocker. Pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion).

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M58.

Thank you.

Does this still happen on ToT (r453128)? I cannot reproduce the issue (although I'm missing something).

Rechecked this on chrome version 58.0.3024.0 & 57.0.2987.74 on Windows 10, MAC 10.12.3 and still able to reproduce it. Followed the below steps:

1) Launch chrome and navigated to www.priceline.com
2) Pasted the following snippet in console on the page :-

 childWin=window.open('about:blank', 'chrome57', 'scrollbars="yes",resizable="yes",height=450,width=450,top=9999,left=9999');
 scriptE = childWin.document.createElement("script");
 scriptE.innerHTML = 'window.location.href="https://www.bookingbuddy.com/en/holding/"';
 childWin.document.head.appendChild(scriptE);

3) A child Window was opened with "https://www.bookingbuddy.com/en/holding/" and asking to please wait..
4) Left the window open for couple of minutes and then with focus back on In the main window (www.priceline.com)  pasted the below code in console:

 childWin.location.href='https://www.priceline.com/';

As per actual behavior mentioned above DID NOT see the below error in console:

 VM569:1 Uncaught TypeError: no access
     at <anonymous>:1:2
 (anonymous) @ VM569:1

But at the same time as per expected behavior "at end of step 3 it should have navigated the child window to https://www.priceline.com/" DID NOT happen.

Thanks.!

Note: Same behavior mentioned in comment#12 is observed on MAC 10.12.3 for chrome version 58.0.3025.0 (regular & incognito Window).

Please let me know if I have missed out anything here.

Thanks.!

Hmm, I was able to reproduce it on Mac and Win but couldn't reproduce it on Linux.

Also it looks like that the bug is timing sensitive. For some reason we need to wait for a couple of mins to reproduce it.

- Are you really sure that https://chromium.googlesource.com/chromium/src/+log/950a485a..40458d4d?pretty=fuller is the culprit range?

- Is this really a stable-block bug?

 haraken@  Please find the replies for the questions in Comment#14

- Yes I have bisected the issues twice and both lead to the CL : https://chromium.googlesource.com/chromium/src/+/40458d4dd913d5fd6f4f1bb2da083a8a7136a9af

- I am not sure since if this should be a stable blocker since it's hard to say what's the impact and how often this approach is followed in real world webpage implementation and I am not right person to asses that. But can say that priceline.com is major webpage AFAIK.

URGENT - PTAL ASAP.

A friendly reminder that M57 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch by Friday (03/03), 5:00 PM PST in order to make into the desktop Stable final build cut. Thank you!

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M58.

Thank you.

I am not sure what is it taking so much time for something which is per standards only for sake of some refactoring ?
Are we telling via reluctance to fix (or revert the revision altogether) that, well if you are performing the above use case please include atleast  an empty script tag??

IMHO, I bet this will break a quiet a few no script sites!

> - Yes I have bisected the issues twice and both lead to the CL : https://chromium.googlesource.com/chromium/src/+/40458d4dd913d5fd6f4f1bb2da083a8a7136a9af

Thanks, will take a look again.

> I am not sure what is it taking so much time for something which is per standards only for sake of some refactoring ?

We have landed a lot of changes on top of the refactoring, so it's very hard to revert it.

Is there a self-contained repro? I tried to make a self-contained repro using an iframe, but couldn't get it to work. Is it crucial to use the inspector console as part of the repro steps?

I'm sorry I didn't have time to debug this (I'll be traveling from tomorrow...).

yukishiino@: I apologize, but would you mind taking a look at this bug?

The repro step is written in #12. I can repro the bug only on Mac and Win (but undeterministically) but cannot repro it on Linux.

Re #17: I don't quite understand how this bug is related to no script sites. Maybe can you create a minimized repro case?

dcheng@ It is not needed to use inspector console. However to make it self contained
Our partner (the step to open child window (https://www.bookingbuddy.com/en/holding/) Updated their web code as a workaround to add empty script tag (since it was getting so close to stable release). 

If you have another link which does not have the empty script tag it still reproduces.
I can request them to host a test page without the script tag again if needed.

My guess:
The exception is because we detached the global object from the global proxy, but then we never reinitialize it. Normally, we make sure a WindowProxy is initialized when we return it to JS in https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/ToV8.cpp?rcl=e506b1518fc4633aee4f2b32193de02f987a0096&l=28: Frame::windowProxy() (by chance) guarantees that the returned WindowProxy will be initialized.

However, we already have a JS reference in this case, so we don't go through the ToV8 path. The result is when we try to access the Location property, v8 denies the access because the WindowProxy is not reinitialized. Adding a <script> tag forces reinitialization of the WindowProxy, which is why you see that difference.

In order to fix this, we will need to always reinitialize the WindowProxy after navigation, if WindowProxy was previously initialized. I'm going to try to reduce a test case for this... after that, we can test the fix and make sure it works.

OK, I've reduced this in a unit test. Working on a fix, will try to send out shortly.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bee44e2b6c7a93b28e1082743784045447498476

commit bee44e2b6c7a93b28e1082743784045447498476
Author: dcheng <dcheng@chromium.org>
Date: Fri Mar 03 09:24:58 2017

Ensure WindowProxy reinitialization on navigations if needed.

When returning a Window reference to JS, Blink calls ToV8() to
convert the C++ DOMWindow pointer to an associated JS DOM wrapper,
which ensures the associated WindowProxy is initialized. During a
navigation that requires switching DOMWindows, the WindowProxy is
detached from the old DOMWindow by calling setDOMWindow() and
later reattached to the new DOMWindow by calling
ScriptController::updateDocument().

As an optimization, 246e25c5bd72fac9dce3b9b1254e5590d0444d09
skipped initialization of the WindowProxy if it's global proxy
reference was null. Skipping initialization is safe here since a
null global proxy reference means that ToV8() was never called,
and JS cannot hold any references to the Window object. Thus, it
is unnecessary to ensure that the global proxy is attached to a
DOMWindow.

40458d4dd913d5fd6f4f1bb2da083a8a7136a9af cleaned up the complex
WindowProxy initialization logic but introduced a subtle bug:
it changed updateDocument() to be a no-op if the WindowProxy is
not initialized. Unfortunately, this means that any existing
script references to that Window object will be broken unless
WindowProxy reinitialization is triggered by something else,
such as loading a <script> tag in the new Document or getting
a new reference to the Window.

BUG= 690178 

Review-Url: https://codereview.chromium.org/2732483004
Cr-Commit-Position: refs/heads/master@{#454552}

[modify] https://crrev.com/bee44e2b6c7a93b28e1082743784045447498476/third_party/WebKit/Source/bindings/core/v8/LocalWindowProxy.cpp
[modify] https://crrev.com/bee44e2b6c7a93b28e1082743784045447498476/third_party/WebKit/Source/bindings/core/v8/LocalWindowProxy.h
[modify] https://crrev.com/bee44e2b6c7a93b28e1082743784045447498476/third_party/WebKit/Source/web/BUILD.gn
[add] https://crrev.com/bee44e2b6c7a93b28e1082743784045447498476/third_party/WebKit/Source/web/tests/WindowProxyTest.cpp
[modify] https://crrev.com/bee44e2b6c7a93b28e1082743784045447498476/third_party/WebKit/Source/web/tests/sim/SimTest.cpp
[modify] https://crrev.com/bee44e2b6c7a93b28e1082743784045447498476/third_party/WebKit/Source/web/tests/sim/SimTest.h
[add] https://crrev.com/bee44e2b6c7a93b28e1082743784045447498476/third_party/WebKit/Source/web/tests/sim/SimWebFrameClient.cpp
[add] https://crrev.com/bee44e2b6c7a93b28e1082743784045447498476/third_party/WebKit/Source/web/tests/sim/SimWebFrameClient.h

Thank you dcheng@. Please request a merge to M57 branch 2987 once change is baked/verified in Canary and safe to merge to M57. 

I've confirmed locally that this fixes the bug. Going to see how it looks in Canary (and if it addresses the M58 crashes that this seems to cause)

[Auto-generated comment by a script] We noticed that this issue is targeted for M-57; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-57 label, otherwise remove Merge-TBD label. Thanks.

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The M58 crash doesn't seem to be affected by this patch; however, M57 doesn't have this crash, and canary doesn't appear to have any new crashes due to this patch, so it should be safe to merge.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/95f5677a57769e83d805ec813aea89e215d658ad

commit 95f5677a57769e83d805ec813aea89e215d658ad
Author: Daniel Cheng <dcheng@chromium.org>
Date: Sat Mar 04 18:42:33 2017

Ensure WindowProxy reinitialization on navigations if needed.

When returning a Window reference to JS, Blink calls ToV8() to
convert the C++ DOMWindow pointer to an associated JS DOM wrapper,
which ensures the associated WindowProxy is initialized. During a
navigation that requires switching DOMWindows, the WindowProxy is
detached from the old DOMWindow by calling setDOMWindow() and
later reattached to the new DOMWindow by calling
ScriptController::updateDocument().

As an optimization, 246e25c5bd72fac9dce3b9b1254e5590d0444d09
skipped initialization of the WindowProxy if it's global proxy
reference was null. Skipping initialization is safe here since a
null global proxy reference means that ToV8() was never called,
and JS cannot hold any references to the Window object. Thus, it
is unnecessary to ensure that the global proxy is attached to a
DOMWindow.

40458d4dd913d5fd6f4f1bb2da083a8a7136a9af cleaned up the complex
WindowProxy initialization logic but introduced a subtle bug:
it changed updateDocument() to be a no-op if the WindowProxy is
not initialized. Unfortunately, this means that any existing
script references to that Window object will be broken unless
WindowProxy reinitialization is triggered by something else,
such as loading a <script> tag in the new Document or getting
a new reference to the Window.

BUG= 690178 

Review-Url: https://codereview.chromium.org/2732483004
Cr-Commit-Position: refs/heads/master@{#454552}
(cherry picked from commit bee44e2b6c7a93b28e1082743784045447498476)

Review-Url: https://codereview.chromium.org/2735573002 .
Cr-Commit-Position: refs/branch-heads/2987@{#765}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/95f5677a57769e83d805ec813aea89e215d658ad/third_party/WebKit/Source/bindings/core/v8/LocalWindowProxy.cpp
[modify] https://crrev.com/95f5677a57769e83d805ec813aea89e215d658ad/third_party/WebKit/Source/bindings/core/v8/LocalWindowProxy.h
[modify] https://crrev.com/95f5677a57769e83d805ec813aea89e215d658ad/third_party/WebKit/Source/web/BUILD.gn
[add] https://crrev.com/95f5677a57769e83d805ec813aea89e215d658ad/third_party/WebKit/Source/web/tests/WindowProxyTest.cpp
[modify] https://crrev.com/95f5677a57769e83d805ec813aea89e215d658ad/third_party/WebKit/Source/web/tests/sim/SimTest.cpp
[modify] https://crrev.com/95f5677a57769e83d805ec813aea89e215d658ad/third_party/WebKit/Source/web/tests/sim/SimTest.h
[add] https://crrev.com/95f5677a57769e83d805ec813aea89e215d658ad/third_party/WebKit/Source/web/tests/sim/SimWebFrameClient.cpp
[add] https://crrev.com/95f5677a57769e83d805ec813aea89e215d658ad/third_party/WebKit/Source/web/tests/sim/SimWebFrameClient.h

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@dcheng: Can you please help us with a reduced test case as we are still observing the same behavior as mentioned in comment# 12. This will help us to verify the issue from our end on canary.

Thanks.!

ranjitkan@: what repro steps are you using? I've been unable to repro the original steps at all, even in a release that proceeds my patch landing.

I manually tested using something like this:

1. navigate to about:blank
2. In devconsole:
   childWindow = window.open();
   childWindow.location = 'data:text/plain,Hi';
3. Once it's loaded, then in devconsole:
   childWindow.location = 'about:blank';

Which fails without my patch and works with it.

Please merge your change to M58 Branch 3029 before 5PM PDT tomorrow (Tuesday 3/7), so this can be picked up for Dev release on Thursday. 

Rechecked the issue on chrome version 59.0.3032.0 as per the steps mentioned in Comment#36. Fix is working as intended. Adding TE- Verified labels.

Thanks.!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4933ae6d5fe4a43fd7d2cbb0017e1492ab455b92

commit 4933ae6d5fe4a43fd7d2cbb0017e1492ab455b92
Author: Daniel Cheng <dcheng@chromium.org>
Date: Tue Mar 07 06:35:03 2017

Ensure WindowProxy reinitialization on navigations if needed.

When returning a Window reference to JS, Blink calls ToV8() to
convert the C++ DOMWindow pointer to an associated JS DOM wrapper,
which ensures the associated WindowProxy is initialized. During a
navigation that requires switching DOMWindows, the WindowProxy is
detached from the old DOMWindow by calling setDOMWindow() and
later reattached to the new DOMWindow by calling
ScriptController::updateDocument().

As an optimization, 246e25c5bd72fac9dce3b9b1254e5590d0444d09
skipped initialization of the WindowProxy if it's global proxy
reference was null. Skipping initialization is safe here since a
null global proxy reference means that ToV8() was never called,
and JS cannot hold any references to the Window object. Thus, it
is unnecessary to ensure that the global proxy is attached to a
DOMWindow.

40458d4dd913d5fd6f4f1bb2da083a8a7136a9af cleaned up the complex
WindowProxy initialization logic but introduced a subtle bug:
it changed updateDocument() to be a no-op if the WindowProxy is
not initialized. Unfortunately, this means that any existing
script references to that Window object will be broken unless
WindowProxy reinitialization is triggered by something else,
such as loading a <script> tag in the new Document or getting
a new reference to the Window.

BUG= 690178 

Review-Url: https://codereview.chromium.org/2732483004
Cr-Commit-Position: refs/heads/master@{#454552}
(cherry picked from commit bee44e2b6c7a93b28e1082743784045447498476)

Review-Url: https://codereview.chromium.org/2735983002 .
Cr-Commit-Position: refs/branch-heads/3029@{#37}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/4933ae6d5fe4a43fd7d2cbb0017e1492ab455b92/third_party/WebKit/Source/bindings/core/v8/LocalWindowProxy.cpp
[modify] https://crrev.com/4933ae6d5fe4a43fd7d2cbb0017e1492ab455b92/third_party/WebKit/Source/bindings/core/v8/LocalWindowProxy.h
[modify] https://crrev.com/4933ae6d5fe4a43fd7d2cbb0017e1492ab455b92/third_party/WebKit/Source/web/BUILD.gn
[add] https://crrev.com/4933ae6d5fe4a43fd7d2cbb0017e1492ab455b92/third_party/WebKit/Source/web/tests/WindowProxyTest.cpp
[modify] https://crrev.com/4933ae6d5fe4a43fd7d2cbb0017e1492ab455b92/third_party/WebKit/Source/web/tests/sim/SimTest.cpp
[modify] https://crrev.com/4933ae6d5fe4a43fd7d2cbb0017e1492ab455b92/third_party/WebKit/Source/web/tests/sim/SimTest.h
[add] https://crrev.com/4933ae6d5fe4a43fd7d2cbb0017e1492ab455b92/third_party/WebKit/Source/web/tests/sim/SimWebFrameClient.cpp
[add] https://crrev.com/4933ae6d5fe4a43fd7d2cbb0017e1492ab455b92/third_party/WebKit/Source/web/tests/sim/SimWebFrameClient.h

Rechecked the issue on chrome version 57.0.2987.96 on Windows 10, MAC 10.12.3, ubuntu 14.04 as per the steps mentioned in Comment#36. Fix is working as intended. Adding TE- Verified labels.

Thanks.!