If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[DOM] Events on the BODY node

VERIFIED WORKSFORME

Status

()

Core
DOM: Events
P2
normal
VERIFIED WORKSFORME
19 years ago
11 years ago

People

(Reporter: Erik Arvidsson, Assigned: joki (gone))

Tracking

({dom1, testcase})

Trunk
mozilla1.0.1
x86
Windows 98
dom1, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Assignee: vidur → joki

Updated

19 years ago
QA Contact: 4015 → 3847
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M6
(Assignee)

Comment 1

19 years ago
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.
(Assignee)

Comment 2

19 years ago
Moving out to M7
(Assignee)

Updated

19 years ago
Target Milestone: M7 → M9

Updated

18 years ago
Whiteboard: [MAKINGTEST] jonesev@home.com (26/07/99)

Comment 3

18 years ago
Created attachment 1002 [details]
Observe the alerts and watch what tag received the events

Updated

18 years ago
Whiteboard: [MAKINGTEST] jonesev@home.com (26/07/99) → [TESTCASE] The BODY tag should recieve the event, not HTML (26/07/99)

Comment 4

18 years ago
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.
(Assignee)

Updated

18 years ago
Priority: P2 → P4
Target Milestone: M9 → M11
(Assignee)

Comment 5

18 years ago
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.

Comment 6

18 years ago
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

Updated

18 years ago
Blocks: 10702

Comment 7

18 years ago
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.
(Assignee)

Comment 8

18 years ago
Moving multiple bugs to m12

Comment 9

18 years ago
Moving to m13 because Joki seems to be distracted.
(Assignee)

Updated

18 years ago
Target Milestone: M13 → M15
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
(Assignee)

Comment 11

18 years ago
Mass-moving bugs out of M15 that I won't get to.  Will refit individual 
milestones after moving them.
Target Milestone: M15 → M16

Comment 12

18 years ago
M16 has been out for a while now, these bugs target milestones need to be 
updated.
(Assignee)

Comment 13

18 years ago
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
(Assignee)

Updated

18 years ago
Target Milestone: M16 → M18
(Assignee)

Comment 14

18 years ago
Updating Milestone to M18.

Comment 15

17 years ago
PDT:  Nominating nsbeta3+.  Standards Compliance.
Keywords: nsbeta3
I am the virtual joki.
Assignee: joki → heikki
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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)
Priority: P4 → P2
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

Updated

17 years ago
Keywords: relnote3
Sending most of my events bugs to joki.
Assignee: heikki → joki
Status: ASSIGNED → NEW

Comment 21

17 years ago
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
(Assignee)

Comment 23

17 years ago
*** Bug 73940 has been marked as a duplicate of this bug. ***

Comment 24

17 years ago
not my area, off to desale
QA Contact: janc → desale

Comment 25

17 years ago
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala

Comment 26

16 years ago
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)

Comment 27

16 years ago
Vladimir, the described failure is about the event.target property, in DOM 2 Events.

QA Contact: stummala → vladimire

Comment 28

16 years ago
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

Comment 29

16 years ago
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.
Attachment #1002 - Attachment is obsolete: true

Comment 30

15 years ago
I confirm everything said in comment #29. Attachment 63566 [details] WFM without a
problem. XP Pro SP1 and build 2002112204.

Comment 31

15 years ago
wfm based on coments, and the last testcase. 
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 32

15 years ago
verifying
Status: RESOLVED → VERIFIED

Comment 33

11 years ago
If this is working can someone update: http://www.mozilla.org/docs/dom/mozilla/bug-events.html

Comment 34

11 years ago
http://www.mozilla.org/docs/dom/mozilla/bug-events.html
 
has been updated accordingly.
You need to log in before you can comment on or make changes to this bug.