Open
Bug 919189
Opened 11 years ago
Updated 2 years ago
Infinite loop of page leaving confirmation
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
NEW
People
(Reporter: marc.parker-321jbyw, Unassigned)
Details
(Whiteboard: DUPEME)
Attachments
(1 file)
139 bytes,
text/html
|
Details |
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
Updated•11 years ago
|
Assignee: nobody → general
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Updated•11 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 1•11 years ago
|
||
Confirmed in FF 24, 27 Win 7
Updated•11 years ago
|
Assignee: general → nobody
Component: JavaScript Engine → Document Navigation
Comment 3•11 years ago
|
||
(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
Updated•11 years ago
|
Whiteboard: DUPEME
Comment 4•11 years ago
|
||
(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.
Comment 5•11 years ago
|
||
(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 ?
Comment 6•11 years ago
|
||
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.
Comment 7•11 years ago
|
||
(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.
Comment 8•11 years ago
|
||
(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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•