dcheng, is there a good label to put on bugs which are triggered by navigation-type stuff like this? I'm not confident this is just bindings.

I can't repro; do you mind providing the test file you're using?

My test file is currently:
<script>window.ID = 42</script>

When I navigate somewhere else and then back, the window.ID assignment doesn't seem to fail.

FWIW I can't reproduce this either on Linux 56.0.2924.87 (Official Build) (64-bit) with a page like this:

data:text/html,<script>window.ID=42;alert(window.ID === 42);</script><a href="http://google.com">go</a>

Could you provide a specific web page we can use to try to reproduce this?

Ok, this issue was not as easy to repro as i initially thought. It seems to be related to somekind of coors / session. But as for now i could not yet pinpoint the exact issue. Ill investigate further and will report back here.

Thank you for providing more feedback. Adding requester "dominicc@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

storm.patrik@ could you please provide any latest update regarding this issue.

Thank You...

I can also replicate this issue in Chrome 56 and 57 with cookie cache all disabled. As said, the issue is very hard to replicate and only seems to occur in an edge case. Here is my steps to replicate:
1. Create a chrome extension that takes over chrome new tab.
2. In the extension new tab, embed an iframe that loads a webpage, for example: http://www.test.com/index.html. 
3. In http://www.test.com/index.html, put some JavaScript to access the window variable. For example: 
setInterval(function(){window.test = 'test'; console.log(window.test)}, 50);
4. Install such extension on your Chrome, so that whenever you open a new tab, you will be shown a page with an iframe that loads http://www.test.com/index.html
5. Open a new tab, at the same time, load http://www.test.com/index.html (the url that is set in the iframe) in the address bar on the same tab. You will have a chance to get the error "Uncaught TypeError: no access" at the lines where it tries to access the window variable (window.test = 'test' or console.log(window.test))

It looks like there is a lock on access to the "window" variable so that when the page in the new tab iframe gets the access to the "window" variable, it locks out the other page with the same domain that you are trying to navigate to on the same tab, in which case you will see "Uncaught TypeError: no access" error.

Ah, I didn't know extensions were involved. This is a bug that's fixed (with the fix merged to M58).

kkaluri@ Well, i actually just worked around this issue as I really never got to pinpoint the factor involved. Still my browser HAS some extensions, i did not consider them as a culprit...

As previously noted this very hard to reproduce, but i still get the bug when accessing my application that does use HTTPS + cookies as a auth mechanism.