Open Bug 919189 Opened 11 years ago Updated 2 years ago

Infinite loop of page leaving confirmation

Categories

(Core :: DOM: Navigation, defect)

24 Branch
x86_64
Windows 8
defect

Tracking

()

People

(Reporter: marc.parker-321jbyw, Unassigned)

Details

(Whiteboard: DUPEME)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release) Build ID: 20130910160258 Steps to reproduce: URL: http://1488.pro/el/ Src: <script>onbeforeunload=function(){location.reload();return 1};onload=function(){location.reload();}</script> Actual results: Infinite loop of leaving the page confirmations Expected results: Only one confirmation
Assignee: nobody → general
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed in FF 24, 27 Win 7
Assignee: general → nobody
Component: JavaScript Engine → Document Navigation
Should check what the spec says here.
Keywords: qawanted
(In reply to Boris Zbarsky [:bz] from comment #2) > Should check what the spec says here. This is happening on all browsers and all OS's which is expected. Boris, the script from Comment 0 is calling at infinite the reload function, so the infinite loop of leaving the page confirmations is expected to happen but even so there should be a warning alert or something like that displayed after a couple of reloads.
Keywords: qawanted
Whiteboard: DUPEME
(In reply to Mihai Morar, QA (:MihaiMorar) [away Oct 03 - Oct 07] from comment #3) > after a couple of reloads. Instead of a JavaScript reload, the sample code can be a cyclic redirect. <http://example.com/A.html> -> <http://example.com/B.html> <http://example.com/B.html> -> <http://example.com/C.html> <http://example.com/C.html> -> <http://example.com/A.html> <http://example.com/A.html> -> <http://example.com/B.html> <http://example.com/B.html> -> <http://example.com/C.html> ... Mozilla users can set the maximum number of HTTP redirects (3xx), but can't set that of JavaScript redirect or of REFRESH header redirect. And indeed it's difficult for both browser developers and users to decide how many redirects are safe/dangerous. Probably 10 "Leaving?" dialogs are annoying enough, but 10 redirects might be not.
(In reply to O. Atsushi (Torisugari) from comment #4) > (In reply to Mihai Morar, QA (:MihaiMorar) [away Oct 03 - Oct 07] from > comment #3) > > > after a couple of reloads. > > Instead of a JavaScript reload, the sample code can be a cyclic redirect. > > <http://example.com/A.html> -> <http://example.com/B.html> > <http://example.com/B.html> -> <http://example.com/C.html> > <http://example.com/C.html> -> <http://example.com/A.html> > <http://example.com/A.html> -> <http://example.com/B.html> > <http://example.com/B.html> -> <http://example.com/C.html> > ... > > Mozilla users can set the maximum number of HTTP redirects (3xx), but can't > set that of JavaScript redirect or of REFRESH header redirect. And indeed > it's difficult for both browser developers and users to decide how many > redirects are safe/dangerous. Probably 10 "Leaving?" dialogs are annoying > enough, but 10 redirects might be not. This makes sens. I didn't know the simple code can be a cyclic redirect. Can this be duplicate of Bug 769517 or Bug 487498 ?
According to html5 spec, UAs are not allowed to call |window.open(...)| while "beforeunload" event handlers are being processed. http://www.w3.org/TR/2013/CR-html5-20130806/browsers.html#unloading-documents http://www.w3.org/TR/2013/CR-html5-20130806/dom.html#ignore-opens-during-unload-counter And Google Chrome seems to be implemented as expected. But Firefox is not. So we should fix this problem first. I'm not too sure there exists a dup bug about this issue on b.m.o. --- StR: 1. Visit the testcase 2. Close the tab. Expected result: Do nothing. Actual result : Loads "http://www.mozilla.org/". --- Then, afaik, Webkit/Blink family allows to call |location.reload()|. And the spec does not say anything about reloads, well, explicitly. However, in my opinion, Gecko should ignore |location.reload()|, |history.back()| or any sorts of document-loads besides |window.open(...)|. And hopefully we should rename spec's "ignore-opens-during-unload-counter" with "ignore-new-loading-during-unload-counter" or something.
(In reply to O. Atsushi (Torisugari) from comment #6) Using your testcase on Latest Nightly 27, after I open the testcase in a new tab, that tab got freezed and I am not able to close it. No confirmation message is displayed about "if I want to close it". On Chrome opening your testcase and closing the tab, I am asked only once "if I want to close it" and then the tab is fully closed without any problem.
(In reply to Mihai Morar, QA (:MihaiMorar) from comment #7) > Using your testcase on Latest Nightly 27, after I open the testcase in a new > tab, that tab got freezed and I am not able to close it. No confirmation > message is displayed about "if I want to close it". That seems similar to bug 705617. But I can't reproduce such a freeze, with both release Firefox 24.0 (Windows) and today's nightly (Ubuntu). Is it a MacOSX specific problem? > On Chrome opening your testcase and closing the tab, I am asked only once > "if I want to close it" and then the tab is fully closed without any problem. And IE10 is also broken. Good : Chrome Bad : Firefox24, IE10
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: