-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define when navigator and location objects are replaced #2545
Comments
Is this all entangled with the reasons that WindowProxy exist, perhaps? |
This came up in https://codereview.chromium.org/2805763004 where I wanted to propose something like an "is active" check for the navigator object. |
Yeah, WindowProxy typically persists, but its underlying Window object definitely changes upon navigation (unless initial about:blank). |
The spec here is pretty bad for Navigator:
It could be any instance! The entire browser could share a single instance!! Ugh. For Location it's much better:
and Window objects are created explicitly during navigation and other scenarios. |
I wrote this test:
Note that History objects are technically associated with documents, so it should change here, but in Firefox it does not and it passes the test. However, in Chrome and Safari I get
which I'm not sure what to do with. |
It looks like the exception is thrown when test harness tries to construct a string for the error message from frameLocation. All those assertions fail in WebKit, we do not return the same objects after the navigation. Therefore, frameLocation is in a state where it throws when trying to do whatever the test harness does. |
That seems like a bug in itself as everything is same-origin and nothing would end up throwing like that (it seems to simply try to ToString it). And not returning the same object is a bug too. I guess all this is even less interoperable than I thought. |
I believe our location object relies on having a frame to be useful. However, after the navigation, it seems we create a new Location object and the old one ends up being frameless. |
If I reduce my above test to just I think what Firefox does makes the most sense, unless we really want to tie all these objects to |
Created a test for
Once we make progress there I'd propose we make History and Navigator per-global as well. |
Wow, thanks for the excellent research! I've merged web-platform-tests/wpt#5778, do you think we should wait for that to be sorted out implementation-side before doing anything further here? |
Yeah, I'm wondering whether Chromium and WebKit have architectural reasons for having almost everything associated with |
I'm not sure either. A change like this might end up with @tkent-google to ponder, WDYT? |
I guess fixing this is not easy due to out-of-process iframe. |
I'm actually now confused how it can work securely to associate things with the global object. If you grab a reference to this associated thing and then navigate the initial about:blank frame cross-origin, what happens? @bzbarsky how does Firefox handle that? |
The same thing that happens when you navigate any other page cross-origin. You get a new global object, with a different origin from the old global object. The things you were holding on to are still referencing the old global object. Do you have a specific scenario or API you're concerned about? |
Thanks, I had just missed that replacement only happens same-origin. @tkent-google so what exactly is the issue with out-of-process child documents then? |
I don't have an idea of exact technical issues at this moment. It's just a guess, and I don't think fixing it is impossible. |
The
document
attribute returns the associated Document and thehistory
attribute is defined in terms of that as well.For
navigator
andlocation
, there isn't anything to suggest that these objects are replaced when navigating an iframe.https://jsbin.com/jagiruh/edit?html,output is a test that passes in Chrome, Firefox and Safari, showing that a bunch of objects are replaced when navigating an iframe. It fails with "Permission denied" in Edge.
The text was updated successfully, but these errors were encountered: