292943 - Can retarget trusted events to unexpected nodes

Status: RESOLVED DUPLICATE of bug 296704

(Core :: DOM: Events, defect)

Description

[Boris Zbarsky [:bzbarsky]]

This is a variant on the bug we had where the page dispatched a DOMLinkAdded
event on a non-link node so that when the chrome saw the event and read the
"rel" property it ended up doing unexpected things.

The basic problem is that the page can call dispatchEvent on an
already-dispatching event to redispatch it to a new node.  Testcase coming up to
demonstrate this.

If the DOM spec doesn't require that we support this, I'd suggest having a flag
on events that prevents them from being dispatched more than once.

If it _does_ require that we support this, I'm not sure what we should do. 
Perhaps the same thing anyway...

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase.

To test, enable the link toolbar and load the testcase.  Note that the
"Previous" link in the link toolbar is enabled...

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Can we save and restore the trusted flag, so that it's unset during the dispatch
from the page?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Yeah, that should be doable...

Comment 4

[Daniel Veditz [:dveditz]]

should we clone a trusted event if it's redispatched by untrusted content?

Comment 5

[Hixie (not reading bugmail)]

I see nothing wrong with allowing trusted events to be redispatched, so long as
we untrust it first. After all, you can always create a new event that is
otherwise equivalent and dispatch that.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> I see nothing wrong with allowing trusted events to be redispatched

Depends on whather doing that also messes with the event target such that
further dispatch for the original event is broken...  It doesn't seem to, and I
can't see _why_.

Comment 7

[Hixie (not reading bugmail)]

By "I see nothing wrong" I meant that given a perfect implementation, it seems
fine. If there are bugs, that's another story -- but you can get bugs with any
feature, that has little to do with design questions (beyond the fact that some
designs are more bug-prone than others, of course).

Comment 8

[Johnny Stenback (:jst)]

This is really the same as bug 296704. Duping to it, since that's where the work
for this ended up being done, even if this bug is older...

*** This bug has been marked as a duplicate of 296704 ***

Comment 9

[Daniel Veditz [:dveditz]]

Clearing branch blocking flags