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)

x86
Windows NT
defect

Tracking

()

VERIFIED INVALID

People

(Reporter: andrew.ng, Assigned: joki)

References

Details

(Whiteboard: [nsbeta2-])

Attachments

(1 file)

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.
Attached file TD in yellow, span in blue (deleted) —
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
need info: What is the downside for the enduser? How common is this used? Which top 100 sites? cc ekrock.
Whiteboard: [need info]
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.
Keywords: nsbeta3, rtm
Whiteboard: [need info]
nsbeta2-
Whiteboard: [nsbeta2-]
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
verified invalid
Status: RESOLVED → VERIFIED
*** Bug 170215 has been marked as a duplicate of this bug. ***
Continued in bug 103055 and bug 185889.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: