Closed Bug 3140 Opened 26 years ago Closed 22 years ago

[DOM] Events on the BODY node

Categories

(Core :: DOM: Events, defect, P2)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.0.1

People

(Reporter: erik, Assigned: joki)

References

(
URL
)

Details

(Keywords: dom1, testcase, Whiteboard: [nsbeta3-]The BODY tag should recieve the event, not HTML (26/07/99))

Attachments

(1 file, 1 obsolete file)

testcase
(deleted), text/html
Details
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.
Assignee: vidur → joki
QA Contact: 4015 → 3847
Status: NEW → ASSIGNED
Target Milestone: M6
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
Target Milestone: M7 → M9
Whiteboard: [MAKINGTEST] jonesev@home.com (26/07/99)
Whiteboard: [MAKINGTEST] jonesev@home.com (26/07/99) → [TESTCASE] The BODY tag should recieve the event, not HTML (26/07/99)
To create the test case (bugathon) I simply reformatted the URL that is listed above (created by d96erik@dtek.chalmers.se) 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.
Priority: P2 → P4
Target Milestone: M9 → M11
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
Blocks: 10702
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.
Target Milestone: M13 → M15
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Mass-moving bugs out of M15 that I won't get to. Will refit individual milestones after moving them.
Target Milestone: M15 → M16
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.
Summary: Events on the BODY node → [DOM] Events on the BODY node
Target Milestone: M16 → M18
Updating Milestone to M18.
PDT: Nominating nsbeta3+. Standards Compliance.
Keywords: nsbeta3
I am the virtual joki.
Assignee: joki → heikki
Status: ASSIGNED → NEW
Per discusion with Nisheeth, marking nsbeta3+. Will email ekrock to verify.
Whiteboard: [TESTCASE] The BODY tag should recieve the event, not HTML (26/07/99) → [nsbeta3+][TESTCASE] The BODY tag should recieve the event, not HTML (26/07/99)
Bug triage with nisheeth & ekrock: nsbeta3-. Adding relnote3 keyword.
Keywords: relnote3
Whiteboard: [nsbeta3+][TESTCASE] The BODY tag should recieve the event, not HTML (26/07/99) → [nsbeta3-][TESTCASE] The BODY tag should recieve the event, not HTML (26/07/99)
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.
Target Milestone: M18 → Future
Keywords: relnote3
Sending most of my events bugs to joki.
Assignee: heikki → joki
Status: ASSIGNED → NEW
Nominating for nsbeta1
Keywords: nsbeta3 → nsbeta1
Keywords: dom1
Component: DOM Level 1 → DOM Events
nsbeta1-, but moving to 1.0 to have another look, might be a simple fix.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: Future → mozilla1.0
*** Bug 73940 has been marked as a duplicate of this bug. ***
not my area, off to desale
QA Contact: janc → desale
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala
not my area --- how did i end up as contact person for this
Whiteboard: [nsbeta3-][TESTCASE] The BODY tag should recieve the event, not HTML (26/07/99) → [nsbeta3-]The BODY tag should recieve the event, not HTML (26/07/99)
Vladimir, the described failure is about the event.target property, in DOM 2 Events.
QA Contact: stummala → vladimire
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
Attached file testcase (deleted) —
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.
Attachment #1002 - Attachment is obsolete: true
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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
verifying
Status: RESOLVED → VERIFIED
If this is working can someone update: http://www.mozilla.org/docs/dom/mozilla/bug-events.html
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: