Reset dispatching flags when retargeting to a different target than event's

[nox]

This repeats step 14 in step 4's shortcut of dispatching an event.

[annevk]

This looks good to me. @hayatoito? But maybe we should instead use a "jump to label" thing to avoid introducing more such issues going forward?

We'll also need tests.

[hayatoito]

Looks good to me. As an alternative idae, how about re-ordering steps 1-4?

Moving "1. Set event's dispatch flag"
into after "4. If target is relatedTarget and target is not event’s relatedTarget, then return true."

I think that does not change the semantics, and would make our intention more clear.

[annevk]

Yeah, that is probably best @hayatoito. Thanks!

[nox]

It does change the behaviour, what you suggest wouldn't clear the stop propagation flag etc.

[annevk]

That is true. I guess the question is whether you expect those to be always unset even if the event didn't really end up dispatching. (The main reason they're unset at the end is because listeners might have set them.)

I don't think it matters much what we do since this is new behavior. So we get to decide what makes sense for this edge case (and write tests for it).

I kinda like @hayatoito's fix since it's simple, but I'm willing to go for the alternative if there's a good reason.

[nox]

Before that new behaviour was introduced, there was not a single code path when dispatching an event that wouldn't clear these flags, even when no listener has actually been invoked. I feel like this property of the algorithm should be preserved.

[annevk]

@smaug---- thoughts either way?

[smaug----]

I guess the pr is fine.

[annevk]

I can try work on a new PR for this after #585 lands.

[annevk]

Though maybe I should include it there, once that has had some more review.