(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #3) > > are there spec reasons we can't just stop navigation permanently as soon as > > we fire beforeunload > > At first blush, per spec you can't stop navigation inside beforeunload at > all. Or something. Figuring out what the spec says here is rocket science. > :(
(In reply to Anne (:annevk) from comment #5) > First of all, agreed with bz that this is in need of heavy refactoring. > Unfortunately there has been a lot of that, so I haven't gotten around to it > yet. If we had more editors, maybe... > > Having read through navigate and its various associated algorithms a few > times now, I don't think anything there stops this, since the user is > allowed to navigate elsewhere until the page navigated to actually starts > arriving (at that point navigate starts blocking certain navigation > attempts, though not all). > > Now, we could make tweaks, but that's tricky. E.g., if the user clicks <a > onclick=window.location='/x'>test</a> after dismissing the dialog, should > that fail or work? (In reply to Anne (:annevk) from comment #22) > No, the situation around this specification-wise hasn't really improved from three years ago unfortunately. So... I'm going to be quite tentative here, because I'm very much not an expert, and both of you are. But if I'm reading: https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate Specifically, > If there is a preexisting attempt to navigate browsingContext, and the source browsing context is the same as browsingContext, and that attempt is currently running the unload a document algorithm, then return without affecting the preexisting attempt to navigate browsingContext. > If the prompt to unload algorithm is being run for the active document of browsingContext, then return without affecting the prompt to unload algorithm. I assume that the second of these now does mean that we can avoid navigation from within beforeunload itself, right? I'm guessing (it's a bit hard to tell for me, not knowing where to look in the spec) that we don't unload the current document (ie we don't hit the first cited condition) until we start getting a response for the initial navigation, and so between these two conditions (ie after `beforeunload` and before `unload`), timers (setTimeout etc.) and any other events may trigger JS that starts another navigation, and per spec that should override the earlier navigation. As Anne points out at the end of comment 5, blocking all navigation after 1 navigation has started is tricky. I'm tempted to suggest we try to pass whether a navigation was the result of a user action (similar/using popup blocking state) down to loadinfo in some way, and make user-triggered navigation be un- overridable by webpage navigations. That would, AIUI fix this bug (and all its variations). It's also a bit complex, and I would be happy to hear other alternatives - in particular, I'm quite curious if any of these bugs affect other browsers and what, if any, mitigations they have in place. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1638610 Title: Dependency of JavaScript objects is Misconfigured Browser Crashes. Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Confirmed Bug description: Hey Team , The bug i want to mention here is a denial of service attack that will not allow any kind of redirection on a page crafted by attacker where we have used hyper-links(ahref). The bug can be maliciously used by crafting an HTML file by an attacker and then sending it to the victim clearly showing there is a hyper-link that redirects to lets say (google.com) through status bar but it will not , instead cause denial of service , browser's also hang up and Crashes. I have tested it on the Very Latest Version of Ubuntu LTS Default Browser. Reason: The following script stops the page from being redirected: window.onbeforeunload = function(){ //Unredirectable Page setTimeout("window.location=document.location;",0); } Demo URL : http://hackies.in/Unredirect-Browsers-Test.html Actual results: It should redirect me to the new page , where as it don't redirect to a new page and the browsers Hangs up. Expected results: So dependency of JavaScript objects(window.document) on Href attribute should not be there. Attached POC for References To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1638610/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
