Closed
Bug 456447
Opened 17 years ago
Closed 17 years ago
with browser.tabs.warnOnClose set to true, onBeforeUnload events are executed before user confirmation that tabs are to be closed
Categories
(Firefox :: Tabbed Browser, defect, P1)
Firefox
Tabbed Browser
Tracking
()
VERIFIED
FIXED
Firefox 3.6a1
People
(Reporter: l.villanne, Assigned: mconnor)
References
Details
(Keywords: regression, testcase, verified1.9.1)
Attachments
(2 files)
195 bytes,
text/html
|
Details | |
1.25 KB,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
When you have some tabs in firefox and you want to close it, it ask a confirmation to close all tab.
The event onbeforeunload in javascript was normaly called just before the page was unloaded, but in this case the event is called before that firefox ask the confirmation. If the user press "cancel" the page wasn't unloaded but the code of the event onbeforeunload were executed.
To work it's necessary taht you have alway's the popup of confirmation when you have some tabs and you close firefox.
You can test it with this page :
<html>
<head>
<title></title>
</head>
<body onbeforeunload="alert('test')">
</body>
</html>
Reproducible: Always
Steps to Reproduce:
1.Open the test file with the "onbeforeunload"
2.Open other tab
3.Try to close firefox
4.The message test appear
5.press cancel in the popup of confirmation
Actual Results:
The javascript associated at the event onbeforeunload is executed but the page is not unloaded
Expected Results:
The javascript associated at the event onbeforeunload does not be executed in this case
Comment 1•17 years ago
|
||
Confirmed on Windows XP that the Quit dialog appears after the alert.
This regressed on 15 June 2007 so I assume it was caused by bug 383760.
Blocks: 383760
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression,
testcase
Version: unspecified → Trunk
Comment 2•17 years ago
|
||
Comment 3•17 years ago
|
||
This will work only if browser.tabs.warnOnClose is set to true (default) AND you close a Firefox window with at least 2 opened tabs.
Comment 4•17 years ago
|
||
This is the base cause of bug 427652 and bug 445109, presumably.
Updated•17 years ago
|
Flags: blocking-firefox3.1?
Summary: onbeforeunload is invocaded too early when you would close firefox with some tab → onbeforeunload is called too early when you close firefox with multiple tabs opened
Comment 5•17 years ago
|
||
A better summary could be: onbeforeunload is called before the dialog box of close confirmation
Comment 6•17 years ago
|
||
Regression from Firefox 2, we should fix it. Proper behaviour would be to capture the onBeforeUnload event and dispose of it if the user decides to cancel the close.
--> Tabbed Browser, but I wonder if this requires docshell work?
Component: General → Tabbed Browser
Flags: blocking-firefox3.1? → blocking-firefox3.1+
QA Contact: general → tabbed.browser
Summary: onbeforeunload is called too early when you close firefox with multiple tabs opened → with browser.tabs.warnOnClose set to true, onBeforeUnload events are executed before user confirmation that tabs are to be closed
Target Milestone: --- → Firefox 3.1
![]() |
||
Comment 7•17 years ago
|
||
Depends on where the warnOnClose code hooks in. I'd think if that runs early enough there would be no need for docshell stuff...
Comment 8•17 years ago
|
||
Connor: another regression from bug 383760, which I've apparently decided is something I need you to help out with :)
Assignee: nobody → mconnor
Priority: -- → P1
Assignee | ||
Comment 9•17 years ago
|
||
It seems like we explicitly changed the ordering to prompt after the onbeforeunload calls in that bug, need to dig further to figure out why that is the case.
Status: NEW → ASSIGNED
Comment 10•17 years ago
|
||
Connor tells me he has a patch waiting; please set yourself up with a reviewer, I'd like to get this closed out by tomorrow if possible.
Assignee | ||
Comment 11•17 years ago
|
||
straightforward enough... doesn't fix Bug 474692 but that seems a separate bug, probably longstanding
Attachment #358048 -
Flags: review?(gavin.sharp)
Updated•17 years ago
|
Whiteboard: [needs review gavin]
Updated•17 years ago
|
Attachment #358048 -
Flags: review?(gavin.sharp) → review+
Updated•17 years ago
|
Whiteboard: [needs review gavin] → [has patch]
Updated•17 years ago
|
Whiteboard: [has patch] → [needs landing]
Assignee | ||
Comment 12•17 years ago
|
||
Checked in, branch and trunk.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: in-litmus?
Keywords: fixed1.9.1
Resolution: --- → FIXED
Whiteboard: [needs landing]
Updated•16 years ago
|
Target Milestone: Firefox 3.1 → Firefox 3.5
Comment 13•16 years ago
|
||
Verified fixed on 1.9.2 and 1.9.1 with:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b6pre) Gecko/20091222 Namoroka/3.6b6pre ID:20091222033648
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.6pre) Gecko/20091126 Shiretoko/3.5.6pre ID:20091126031004
Can we get an automated test for it? That shouldn't be too hard.
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Keywords: fixed1.9.1 → verified1.9.1
OS: Windows XP → All
Hardware: x86 → All
Target Milestone: Firefox 3.5 → Firefox 3.6a1
Assignee | ||
Updated•12 years ago
|
Flags: in-litmus?
You need to log in
before you can comment on or make changes to this bug.
Description
•