Closed
Bug 52440
Opened 24 years ago
Closed 16 years ago
Setting unload event on body element via JS doesn't work
Categories
(Core :: DOM: Events, defect)
Core
DOM: Events
Tracking
()
RESOLVED
INVALID
People
(Reporter: mossgraber, Unassigned)
References
Details
(Keywords: dom2)
Attachments
(2 files)
BuildID: 2000080712 (M17) Trying to set an event handler for the "unload"-event via Javascript for the body element does not work. See the appended example. If you try to set the handler with "body.onunload=" or "body.addEventListener" nothing happens. I found a workaround for this, you can set the attribute instead (which is very ugly). Note: Setting the event handler directly for the TAG like "<body onunload="saySomething()"> does also work. Reproducible: Always Steps to Reproduce: 1. Uncomment any of the three lines which try to set the event-handler 2. Load the HTML page 3. Click on link 4. The alert box should appear Actual Results: Nothing happens. Expected Results: Set the event handler. <html> <body> <a href="http://www.iitb.fhg.de">Leave this page...</a> <script> function saySomething () { alert ("I am leaving for home..."); } // Does not work: // document.body.onunload = saySomething; // Does not work: // document.body.addEventListener ("unload", saySomething, false); // Workaround: document.body.setAttribute ("onunload", "saySomething()"); </script> </body> </html>
Comment 1•24 years ago
|
||
Reassigning to joki for further investigation.
Comment 2•24 years ago
|
||
Comment 5•24 years ago
|
||
Assigning and setting milestone.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Updated•24 years ago
|
Component: DOM Level 2 → DOM HTML
Comment 6•24 years ago
|
||
I initially misread this bug. I didn't think that onload was working from script at all. Specifically the problem is that body.onload doesn't work. This is because the body element has historically, since there was no body object, registered its event handlers on the window object. So window.onload works but body.onload does not. We're not sure how this will be set up moving forward. We'll probably set up a convenience method to alias body.onload to be the same as window.onload but for the moment the workarounds are easy so I'm going to mark this future for now.
Summary: Setting unload event via Javascript does not work → Setting unload event on body element via JS doesn't work
Target Milestone: mozilla0.9 → Future
Reporter | ||
Comment 7•24 years ago
|
||
This bug is not about onload it's about onUnload!
Status: ASSIGNED → NEW
Updated•23 years ago
|
Target Milestone: Future → mozilla1.1
Comment 10•20 years ago
|
||
This is odd...
Assignee: joki → events
Component: DOM: HTML → DOM: Events
OS: Windows NT → All
Priority: P3 → --
QA Contact: vidur → ian
Hardware: PC → All
Target Milestone: Future → ---
Comment 11•19 years ago
|
||
Mozilla is not alone in handling unload events unevenly. This test case uses multiple approaches to setting an unload event handler on window and body objects. I tested with IE 6, Firefox 1.0.4, Opera 8.0, Konqueror 3.4, and Safari 2.0. Only Opera supported all the tested methods, but it invokes body unload handlers multiple times. Unfortunately, there is no single method that works for all browsers. I think that the ideal would be for all browsers to support all the tested methods so script authors don't have to work out which method works where, so I'll send this test case to the developers of all the browsers I tested.
Comment 12•19 years ago
|
||
*** Bug 301401 has been marked as a duplicate of this bug. ***
Comment 13•16 years ago
|
||
<html><head> <title>Untitled</title> <script> function st() { alert('Working...'); alert("Other..."); // Working only "Alert" command... Nothing else.... // Browser: Mozilla Firefox 2.0.0.13_Rus, WinXP_Rus } </script> </head> <body onunload='st()'> </body> </html> Working only "Alert" command.... Bug, bug, bug!!!
Comment 14•16 years ago
|
||
What specifically isn't working? We're leaving the page when this event fires, so lots of things either won't work, or you won't see the result before the page is torn down etc.
Comment 15•16 years ago
|
||
Comment #13 - I do see both alerts in FF 3.0.1/mac -- build 2008070206 @jst - the content handler attribute works just fine :-). Calling multiple confirms onunload could be a possible DOS attack. I could see how that could be true with alert, but wouldn't seem to be something a hacker could anywhere with. The body element doesn't have an unonload property. Window does. D3E says the target is Document, though the handler is attached to window (w3c "window denial"). Opera doesn't implement it this way. So: <!DOCTYPE HTML> <html> <head> <title>onunload test</title> <link rel="author" title="Garrett Smith" href="mailto:dhtmlkitchen@gmail.com"/> </head> <body onunload="saySomething(event, this)"> <a href="http://google.com/">Leave this page...</a> <script type="text/javascript"> function saySomething (e) { e = e || event; var target = e.target || e.srcElement; prompt ('[target, this]', [target, this]); } </script> </body> </html> Opera 9.5 [object Window],[object Window] Firefox 3.01 [object HTMLDocument],[object Window] Webkit [object HTMLDocument],[object DOMWindow] The confusion in this bug comes from the fact that the body content handler, - body onunload="st()" - goes to the window, not the body. This is by design. The context and scope are not body, but window. The second example you have both of: document.body.onunload = "OnUnload()"; window.onunload = "OnUnload()"; This is a perfectly valid assignment of a string value to an object property. The string value will not be evaluated. If you wish for onunload to call the OnUnload function, then you should assign the onunload property to the OnUnload function. window.onunload = OnUnload; However, keep in mind that assigning an onunload property to document.body is not the same as giving document.body an event handler attribute. I think this bug is INVALID. [1]DOM 3 Events http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-unload
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•