When catching events on top level (or in the body node) the target points at the HTML node in cases it should point at BODY node. I'll give you an example. <body onmouseover="alert(event.target.nodeName)"> Gives "HTML" when I enter a "BODY" part of the page.
There are compatibility issues here based on old Navigator behavior for things in the Body tag which reflected into the document (onload, for example). Pushing out to M6 to give more time to resolve these.
Moving out to M7
To create the test case (bugathon) I simply reformatted the URL that is listed above (created by email@example.com) to reduce extraneous tags. I tested it both in Win95 and in Linux on the 1999/07/26 daily build, and this is still broken.
Troy, can I get your comments on this? My question is what should define the body of the doc? In this test, the body no larger than the textual content and thus you immediately mouse into the HTML area, not the BODY. If you expand the content, and therefore the body, you can then hit the body. I think the current behavior may be correct. In any case, not a pressing issue.
From the CSS perspective the BODY isn't special and so the events going to the document element is correct. Certainly for non-HTML documents (e.g., XML) that's what should happen There are some places where the CSS2 spec makes concessions for HTML documents, e.g., the body's background is rendered by the HTML element (unless there's a background specified for the HTML element) So I suppose you could treat events on the HTML element as associated with the BODY element if you wanted to. Only for HTML elements, of course. We won't consider expanding the BODY frame, because the BODY isn't special and can be either block or inline depending on style
Even if it is the correct behavior for the HTML tag to recieve the event, why should that trigger the onMouseOver on the BODY tag, with an event.target.nodeName of HTML? It seems to me that if the target is HTML, the HTML tag should recieve the event, which it does not (See bug 10702). If the event on the body tag recieves the event, shouldn't it have a target.nodeName of BODY? It seems to work that way with every other element.
Moving multiple bugs to m12
Moving to m13 because Joki seems to be distracted.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Mass-moving bugs out of M15 that I won't get to. Will refit individual milestones after moving them.
M16 has been out for a while now, these bugs target milestones need to be updated.
Adding [DOM] prefix to bugs related to DOM Level 0, 1, or 2 compatibility/compliance.
Updating Milestone to M18.
PDT: Nominating nsbeta3+. Standards Compliance.
I am the virtual joki.
17 years ago
Per discusion with Nisheeth, marking nsbeta3+. Will email ekrock to verify.
17 years ago
Bug triage with nisheeth & ekrock: nsbeta3-. Adding relnote3 keyword.
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Sending most of my events bugs to joki.
Nominating for nsbeta1
nsbeta1-, but moving to 1.0 to have another look, might be a simple fix.
*** Bug 73940 has been marked as a duplicate of this bug. ***
not my area, off to desale
Updating QA contact to Shivakiran Tummala.
not my area --- how did i end up as contact person for this
Vladimir, the described failure is about the event.target property, in DOM 2 Events.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Created attachment 63566 [details] testcase The testcase in attachment 1002 [details] is wrong. it does not tell you where the event recieved, just where the originate from. It was always showing HTML because the <body> element had no border or padding (seems like margin doesn't count as part of the body), However the event listener is to the "Window" object as the currentTarget in the testcase I'm attaching shows.
I confirm everything said in comment #29. Attachment 63566 [details] WFM without a problem. XP Pro SP1 and build 2002112204.
wfm based on coments, and the last testcase.
If this is working can someone update: http://www.mozilla.org/docs/dom/mozilla/bug-events.html
http://www.mozilla.org/docs/dom/mozilla/bug-events.html has been updated accordingly.