Open
Bug 197709
Opened 22 years ago
Updated 2 years ago
window.onunload handler is fired on load
Categories
(Core :: DOM: Events, defect, P5)
Core
DOM: Events
Tracking
()
NEW
People
(Reporter: roman, Unassigned)
References
(Depends on 1 open bug, )
Details
Attachments
(1 file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
function wontseeme () { alert("you'll never see this"); };
function willseeme () { alert("I pop up when I should not"); };
otherwin = window.open('other.html', ...);
otherwin.onload = wontseeme;
otherwin.onunload = willseeme;
Reproducible: Always
Steps to Reproduce:
Actual Results:
otherwin.onunload fires when the window is loading.
otherwin.onload does not fire at all.
the js console remains quiet.
Expected Results:
otherwin.onload is fired when the window loads up.
otherwin.onunload is fired when the page is being left, or when the window is
being closed.
I'll attach a test case once I have the PR number.
|
Reporter | |
Comment 1•22 years ago
|
||
a simple test case: http://smradoch.innuendo.cz/mozilla/197709-1.html
|
|
Reporter | |
Comment 2•22 years ago
|
||
btw, if you put
<head>
<script language="javascript1.3">
window.onload = opener.inspect;
window.onunload = opener.inspect;
</script>
</head>
into the popup window instead of assigning the event handlers in the opener,
both events are fired when they should (as witnessed by adding alert(o.type)
into the inspect() function).
|
||
Comment 3•22 years ago
|
||
Sounds like the handlers are attached before the actual load starts, so you're
attaching them to the about:blank document in the new window....
|
|
Reporter | |
Comment 4•22 years ago
|
||
so, is this a bug, or is the behavior undefined? what is the proper way of
decorating a window with code it doesn't know about?
|
|
Reporter | |
Comment 5•22 years ago
|
||
addEventListener is the correct W3 way to get status on a window without
perturbing it, and this is a bug. It has been partially fixed in 1.6b. The load
event now fires: see bug 226416 comment 11 on down. But at this time the unload
event still fires as well.
The problem is a temporary document that's placed in the new window as a
placeholder, to not confuse ubiquitous code that assumes a window will have a
document. That seems like a mistake, but there we are.
Assignee: saari → general
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Comment 7•21 years ago
|
||
Does the temporary about:blank document really need to fire the events?
|
||
Comment 8•21 years ago
|
||
fixing the summary for better search results ( windlow. -> window. )
Summary: windlow.onunload handler is fired on load → window.onunload handler is fired on load
I'm not completely certain. Sometimes the temporary document is never replaced,
so it's not temporary at all. It's probably a 90% solution to mute the temporary
document. It's probably an 80% solution to simply make all about:blank documents
mute.
The only case I can think of where the 90% solution fails is when opening a
window with no URL at all; that is, window.open(), no parameters. Since that's
rarely done and I'm willing to claim it's even more rare that anyone cares to
attach event listeners to such a window, it may be more like a 99% solution. But
I could be overlooking something.
|
|
||
Updated•21 years ago
|
|
||
Comment 10•19 years ago
|
||
|
|
||
Comment 11•19 years ago
|
||
Comment on attachment 194949 [details]
Type in an address or click the link, you'll notice if you view the source, it is the page you should be at. But all you see is the unload.html page.
<HTML><HEAD>
<SCRIPT>
window.unlock = false;
window.onunload=function()
{
if(!window.unlock)
alert("You can't leave");
window.location.href='attachment.cgi?id=194949';
}
document.onmousedown=function()
{
window.unlock = true;
}
</SCRIPT></HEAD>
<BODY>
<A href="http://www.google.com">Link</A><BR/>
</BODY></HTML>
|
|
||
Comment 12•19 years ago
|
||
Comment on attachment 194949 [details]
Type in an address or click the link, you'll notice if you view the source, it is the page you should be at. But all you see is the unload.html page.
<HTML><HEAD>
<SCRIPT>
window.unlock = false;
window.onunload=function()
{
if(!window.unlock)
alert("You can't leave");
window.location.href='attachment.cgi?id=194949';
}
document.onmousedown=function()
{
window.unlock = true;
}
</SCRIPT></HEAD>
<BODY>
<A href="http://www.google.com">Link</A><BR/>
</BODY></HTML>
|
||
Comment 13•19 years ago
|
||
When I open() a specific uri, the unload event should not trigger when about:blank gets unloaded to make room for the requested uri.
|
||
Updated•15 years ago
|
Assignee: general → nobody
QA Contact: desale → events
|
||
Comment 14•12 years ago
|
||
Does this Bug still apply? Is it related to Bug 663753?
|
||
Comment 15•6 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046
Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.
If you have questions, please contact :mdaly.
Priority: -- → P5
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•