Last Comment Bug 191242 - Event propagation quirky with changed EventTarget nodes
: Event propagation quirky with changed EventTarget nodes
Status: RESOLVED FIXED
: testcase
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: x86 Windows 98
: -- normal (vote)
: ---
Assigned To: events
: Hixie (not reading bugmail)
Mentors:
Depends on: 234455
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-29 19:27 PST by Alex Vincent [:WeirdAl]
Modified: 2006-03-07 12:01 PST (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
XUL testcase (2.87 KB, application/vnd.mozilla.xul+xml)
2003-01-29 19:29 PST, Alex Vincent [:WeirdAl]
no flags Details
XHTML testcase (2.84 KB, application/xhtml+xml)
2003-01-29 19:30 PST, Alex Vincent [:WeirdAl]
no flags Details
Create event target chain in stack (1.78 KB, text/plain)
2005-04-03 05:37 PDT, Olli Pettay [:smaug]
no flags Details

Description Alex Vincent [:WeirdAl] 2003-01-29 19:27:37 PST
I've noticed a rather interesting behavior in Mozilla, one which the DOM 2
Events Recommendation and the DOM 3 Events Last Call Working Draft from W3C do
not cover.

Basically, when I replace the actual event target (or likely any ancestor node
of the actual target) with another node, the DOM specs are not clear on correct
behavior.

I'm attaching two testcases, an XUL testcase and an XHTML testcase.  The XUL
testcase is more descriptive, but the XHTML testcase will render in non-Gecko
based browsers as well.

I believe there is at least one bug in the behaviors of the browser here; I'm
just not sure what exactly is "wrong" and what is "correct".
Comment 1 Alex Vincent [:WeirdAl] 2003-01-29 19:29:38 PST
Created attachment 113068 [details]
XUL testcase
Comment 2 Alex Vincent [:WeirdAl] 2003-01-29 19:30:40 PST
Created attachment 113069 [details]
XHTML testcase
Comment 3 Alex Vincent [:WeirdAl] 2003-01-29 19:35:26 PST
jst:  thought you'd like to see this, as a member of the DOM WG.
Comment 4 Alex Vincent [:WeirdAl] 2003-01-29 20:27:17 PST
Running the XUL testcase, the third step, it shows the event propagating through
foo_menu, not bar_menu.  This is clearly a bug.
Comment 5 Johnny Stenback (:jst, jst@mozilla.com) 2003-01-30 16:22:53 PST
Alex, could you send a request to the DOM WG (www-dom@w3.org) to clarify the
intended behavior in the DOM Events specification?
Comment 6 Alex Vincent [:WeirdAl] 2003-01-31 08:46:02 PST
http://lists.w3.org/Archives/Public/www-dom/2003JanMar/0019.html
Comment 7 Alex Vincent [:WeirdAl] 2003-02-05 18:44:03 PST
http://lists.w3.org/Archives/Public/www-dom/2003JanMar/0022.html

The DOM WG's response.

I think Mr. Hegaret is telling us that for the XUL testcase's second part, the
Event object should still go to the target node.
Comment 8 Olli Pettay [:smaug] 2005-04-02 14:33:18 PST
This is how KHTML handles event propagation:
http://lxr.kde.org/source/kdelibs/khtml/xml/dom_nodeimpl.cpp#L416
But is that a bit slow way to do it, creating a node chain for each event...
Comment 9 Olli Pettay [:smaug] 2005-04-03 05:37:50 PDT
Created attachment 179456 [details]
Create event target chain in stack

Any comments on this one?
The idea is to create an event target chain in stack before starting to handle
the event.
This would be quite big change to event handling, but I think something like
this is needed. And hopefully it wouldn't slow down the event handling.
Comment 10 Boris Zbarsky [:bz] 2005-04-03 08:22:21 PDT
Yes, something like this is absolutely needed; there is no other way to
implement the spec.  Yes, this would be a major change to event handling (and
need changes to all the HandleDOMEvent mathods, if nothing else).  See bug
234455.  Any such code should go there, probably.
Comment 11 Olli Pettay [:smaug] 2006-03-07 12:01:02 PST
fixed in bug 234455

Note You need to log in before you can comment on or make changes to this bug.