Closed
Bug 331457
Opened 19 years ago
Closed 18 years ago
onbeforeunload does not prevent firefox close when user presses "cancel" (NS_ERROR_FAILURE [nsIDOMWindowInternal.focus] tabbrowser.xml :: setFocus)
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: bklik, Assigned: moco)
References
Details
(Keywords: testcase)
Attachments
(1 file)
|
(deleted),
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
This issue occurs when there are multiple tabs open and the user is on a tab that "onbeforeunload" is not active on.
Reproducible: Always
Steps to Reproduce:
1. Open a page where "onbeforeunload" is active
2. Open several more tabs and remain on one of the new tabs
3. Close the window, when the "are you sure you wish to navigate away" message comes up, hit cancel and the window will close anyway.
Actual Results:
Firefox closes
Expected Results:
Firefox should not close
|
||
Updated•19 years ago
|
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.8 Branch
|
|
||
Updated•19 years ago
|
Assignee: general → nobody
Component: JavaScript Engine → General
Product: Core → Firefox
QA Contact: general → general
Version: 1.8 Branch → 1.0 Branch
|
|
||
Updated•19 years ago
|
Version: 1.0 Branch → 1.5.0.x Branch
|
||
Comment 1•19 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Tried to reproduce using simple onbeforeunload page coded like this:
<html>
<body>
<script language="javascript" type="text/javascript">
<!--
window.onbeforeunload = function() {
return "Test";
}
-->
</script>
</body>
</html>
Steps Attempted:
1. Open onbeforeunload page on one tab
2. Open second tab at http://www.google.com/
3. Open third tab at http://www.google.com
4. Make third tab active (doesn't seem to matter which one is active)
5. Close window button (not tab close)
6. First tab (onbeforeunload) is made active and "are you sure you wish to navigate away" message is displayed
7. Select "Cancel"
8. Window doesn't close anyway
Tried these steps many times and only got a failure once, when step 8 led to the window closing. I was running javascript console at the time, and this is the error message logged at the time:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowInternal.focus]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/bindings/tabbrowser.xml :: setFocus :: line 744" data: no]
I have not been able to reproduce again. Looks like you an uncaught exception caused Firefox to close, not a misinterpretted onbeforeunload function.
|
||
Comment 2•19 years ago
|
||
Note also bug 327139 and related issues.
Adding relevant parts of the error message to summary.
Summary: onbeforeunload does not provent firefox close when user presses "cancel" → onbeforeunload does not prevent firefox close when user presses "cancel" (NS_ERROR_FAILURE [nsIDOMWindowInternal.focus] tabbrowser.xml :: setFocus)
|
Assignee | |
Comment 3•18 years ago
|
||
confirmed, but this is "fixed" in the trunk and the 1.8.1 branch by my fix for
see bug #348183, especially comment #9 from bryner about what might be going on here.
for the trunk and the 1.8.1 branch, the call to element.focus() is now wrapped
with a try catch:
- element.focus();
+ try {
+ element.focus();
+ }
+ catch(ex) {
+ dump("focus() failed, see bug #348183: ex = " + ex + "\n");
+ }
|
|
Assignee | |
Comment 4•18 years ago
|
||
|
|
Assignee | |
Updated•18 years ago
|
Assignee: nobody → sspitzer
|
||
Comment 5•18 years ago
|
||
I'm planning on backing out the patch for bug 348183 on trunk.
I do that in bug 361383, but it should not result in this bug anymore, since bug 348357 is fixed.
Anyway, this bug is already fixed, and stays fixed, so I'm marking it fixed now.
You need to log in
before you can comment on or make changes to this bug.
Description
•