191960 - [FIXr]DOM events cannot be dispatched to nodes not in the document tree

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Boris Zbarsky [:bzbarsky]]

nsEventListenerManager::DispatchEvent gives up and goes home if its target is
not in a document.  There's no real reason for it to do that (as far as I can
tell, the Events spec just carefully avoids saying what happens when elements
are not in a document and events get dispatched on them).

Patch coming up, but if we'd rather not do this let me know (and tell me how I
_do_ dispatch an event on an element without explicitly getting a prescontext).

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Comment 2

[Johnny Stenback (:jst)]

Comment on attachment 113560 [details] [diff] [review]
Proposed fix

   //If we don't have a target set this doesn't work.
   if (mTarget) {
     nsCOMPtr<nsIContent> targetContent(do_QueryInterface(mTarget));
     if (targetContent) {

Wanna remove the above redundant if (mTarget) check too while you're poking
around here?

sr=jst

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: removes that check

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: same as diff -w

Comment 5

[Johnny Stenback (:jst)]

Comment on attachment 113654 [details] [diff] [review]
same as diff -w

sr=jst

Comment 6

[John Keiser (jkeiser)]

Doing something like this is sort of necessary to implement the spec, which
essentially says that you are supposed to bubble events back to nodes even if
they were removed from the document during the execution of script handlers:

http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020712/events.html#Events-flow-capture

"The chain of EventTargets from the top of the tree to the event's target is
determined before the initial dispatch of the event. If modifications occur to
the tree during event processing, event flow will proceed based on the initial
state of the tree."

It really makes sense to do this anyway--elements which capture fired on should
also be bubbled to, and the element which was targeted should always receive the
event that was targeted at it--so making us one step closer to being able to do
it is a Good Thing.

Comment 7

[Brian Ryner (not reading)]

Comment on attachment 113654 [details] [diff] [review]
same as diff -w

yeah, sounds ok.

Comment 8

[Boris Zbarsky [:bzbarsky]]

checked in for 1.4a.