Closed
Bug 42717
Opened 25 years ago
Closed 25 years ago
mouse events are targeted at textnodes.
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
VERIFIED
INVALID
People
(Reporter: andrew.ng, Assigned: joki)
References
Details
(Whiteboard: [nsbeta2-])
Attachments
(1 file)
(deleted),
text/html
|
Details |
Build ID: 2000060808
Childnode of TD are not identified during an event. I have tried to define the
event directly on the childnode itself but the result is the same. From my
testcase, I tried to display the classname of the element during an onclick.
The TD element is identifed but the childnode SPAN is not identified.
Steps to reproduce:
1. open the testcase
2. click the text "123"
Actual behaviour:
You get the message "class=undefined"
Expected behaviour:
You should get the message "class=SPANClass"
What is happening here is that the target of the event is the textnode not the
span element. This is wrong according to the spec:
"In the case of nested elements, mouse events are always targeted at the most
deeply nested element"
This is why the className attribute is undefined (textnodes dosn't have classes).
Confirming the bug and updating the Summary.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: childnode of TD not identified during event → mouse events are targeted at textnodes.
also nomenating for nsbeta2 since this destroys the entire event.target for
mouse events
Keywords: nsbeta2
Comment 4•25 years ago
|
||
need info: What is the downside for the enduser? How common is this used?
Which top 100 sites? cc ekrock.
Whiteboard: [need info]
Comment 5•25 years ago
|
||
Clearing [need info].
As with all DOM2 bugs, you will not find this functionality currently in use on
Top 100 web sites. However, that doesn't mean it's OK to FUTURE it. DOM2 bugs
need to be evaluated on their impact on (1) standards compliance, and (2)
Gecko's usability as a content and web application across platforms and devices.
This bug is critically severe on both counts. We're directly violating the
standard by targeting events at text nodes instead of the text's enclosing
element. Worse, this renders Gecko unusable as a platform for DOM standard-based
cross-platform/device web applications because developers would have to build
into their code the expectation that events would be targeted at textnodes
instead of at the containing element, which is just plain wrong. We'd be forcing
web application developers to code to a broken implementation of the standard,
and then we'd be prevented from ever fixing this by a large installed base of
code that depended on the broken behavior. Leaving this bug in would be a great
example of "killing the standard" via an initial broken implementation.
Must fix for RTM. Recommend nsbeta2 stopper, else nsbeta3 stopper.
Comment 7•25 years ago
|
||
Marking INVALID. Turns out that the usage of capitalized Element
(exclusive of text nodes) rather than lowercase element (inclusive of text
nodes) in the spec is probably a typo. joki will seek to have this added to the
DOM 2 errata through the committee.
Functionally, we're doing the right thing:
1) There are applications for which it's necessary to be able to determine which
text node the event was targeted at. If we target at the Element rather than its
child text node, we lose the ability to support such applications.
2) In the case where you only want to process events at the granularity level of
the element and it's been targeted at the enclosed child text node, finding the
enclosing parent Element of the text node is a straightforward operation.
... so if we targeted at the element rather than the text node, we'd be losing
information. The applications enabled by our current approach are a proper
superset of those enabled by targeting at the Element, and this approach doesn't
unduly inconvenience those who want Element-level information.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Comment 9•22 years ago
|
||
*** Bug 170215 has been marked as a duplicate of this bug. ***
Comment 10•22 years ago
|
||
Continued in bug 103055 and bug 185889.
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•