Open Bug 1392249 Opened 3 years ago Updated 2 years ago
popup window navigates to another domain but Java
Script from the original domain continues executing
Group: firefox-core-security → dom-core-security
Component: Untriaged → DOM
Product: Firefox → Core
I'm not exactly sure what we want to do in this case. Script in bfcache continues to execute is expected : > In the bfcache case, freezing the window just marks it as frozen; the DOM is preserved, as are compiled script objects. > Thawing marks it as thawed. Freezing suspends timeouts and interval timers on the frozen window, so they won't execute. > The script that's running when the window is frozen runs to completion, as it would if it were being closed We have to guarantee run-to-competition, right?  https://developer.mozilla.org/en-US/docs/Working_with_BFCache
Not familiar with the spec enough... :/ Boris, do you have some comments on what the expected behavior should be in the test case of comment 0?
I was thinking about this last night. Perhaps this behavior is occurring because the line in the POC: window.location.href = "https://www.google.com/" Doesn't add an entry in the history and the BF Cache gets confused?
Per spec, while the alert is up the event loop should be completely frozen and hence the navigation should not complete. This is, obviously, completely user-hostile. That said, I don't think there's a security problem here. In general, script in a navigated-away-from window can run. As a simple example, say the popup just created a function inside itself and handed that function object to the opener. Then it did the navigation. The opener could then wait for the navigation to complete (it can poll for this by using a setInterval to poke properties on the popup until it gets a security exception, say, or the function could get handed back in the unload event in the popup to start with) and then call the function. In that situation most browsers (but not Edge) will run the script. In fact, we have run into sites that expect functions from closed tabs to run in a situation like the above where some other tab is holding on to the function. In terms of its security properties, I don't think using the event-loop-spinning that alert() does to complete the navigation and then unwind into the already-running script is any different than doing the navigation and then getting your code called by the opener.
A couple of notes regarding security. 1. the script continues to run even after the opener is closed. I started experimenting with ways to restart the script after "stop script" message ribbon on the top of the browser is clicked and had some success. 2. postMessage's source is set to the window that has already navigated to the new domain. This is only an issue if a developer trusts the message if it originates from its own window and doesn't check the event's origin. Obviously these are rather minor... I'm happy to continue researching and will report back if I find anything more serious. Let me know your thoughts
(In reply to Boris Zbarsky [:bz] (still digging out from vacation mail) from comment #5) > Per spec, while the alert is up the event loop should be completely frozen > and hence the navigation should not complete. This is, obviously, > completely user-hostile. Maybe you can look into just this part, Samael?
Priority: -- → P3
To be clear, we are very purposefully _not_ implementing the user-hostile part of the spec here. Once quantum DOM is done, we might be able to shut down some of the tabgroup event loop bits and thus prevent the navigation from completing, if we care.
It looks we don't want to change the implementation at this moment.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.