Regression: Event#stopPropagation() does not halt bubbling for webkitTransitionEnd

Regression: Event#stopPropagation() does not halt bubbling for webkitTransitionEnd

If we create a prefixed event to dispatch it (in the case we have only
prefixed event listeners in client's code) then we need to make sure to
keep it in sync with the original unprefixed event after it has been
dispatched. While being dispatched the event can be modified by
client's code and when propagated back to outer elements, attributes were
not updated. This patch changes the old design of creating a separate event
for the prefixed case and now change the type of the event (so the name) before
dispatching it, keeping the attributes if changed and then rename it
back to unprefixed when the dispatching is finished. I've added three tests to cover
the problem.

It's a backport of my own WebKit patch reviewed by Darin Adler :
https://bugs.webkit.org/show_bug.cgi?id=115656

BUG=238379
R=abarth@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=150573

[abarth-chromium, 2013-05-16 21:11:56]

LGTM

https://codereview.chromium.org/15179010/diff/2001/Source/core/dom/EventTarge...
File Source/core/dom/EventTarget.cpp (right):

https://codereview.chromium.org/15179010/diff/2001/Source/core/dom/EventTarge...
Source/core/dom/EventTarget.cpp:195: event->setType(unprefixedTypeName);
Woah

[abarth-chromium, 2013-05-16 21:12:31]

This has some crazy web-visible behavior...  In particular JavaScript can see
the type changing during dispatch.

[darktears, 2013-05-16 21:25:37]

On 2013/05/16 21:12:31, abarth wrote:
> This has some crazy web-visible behavior...  In particular JavaScript can see
> the type changing during dispatch.

Will it actually break something? Does anybody listen event type change for the
webkittransitionend event?

TBH I hope this code path will die with the time. As soon as prefixed only code
is going to be marginal, I'll be more than happy to remove all of that.

The original path was creating a new event and I patched it
https://bugs.webkit.org/attachment.cgi?id=201742&action=review but the proposal
of this cl seemed cleaner.

[abarth-chromium, 2013-05-16 21:30:39]

On 2013/05/16 21:25:37, darktears wrote:
> On 2013/05/16 21:12:31, abarth wrote:
> > This has some crazy web-visible behavior...  In particular JavaScript can
see
> > the type changing during dispatch.
> 
> Will it actually break something? Does anybody listen event type change for
the
> webkittransitionend event?

I don't think it will break anything.  It's just web-exposed and crazy sauce. 
Hence the LGTM.

[commit-bot: I haz the power, 2013-05-17 01:39:37]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alexis.menard@intel.com/15179010/2001

[commit-bot: I haz the power, 2013-05-17 02:41:02]

Retried try job too often on linux_layout_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_layo...

[commit-bot: I haz the power, 2013-05-17 11:34:02]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alexis.menard@intel.com/15179010/2001

[commit-bot: I haz the power, 2013-05-17 12:10:00]

Retried try job too often on linux_layout_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_layo...

[darktears, 2013-05-17 12:27:03]

Committed patchset #2 manually as r150573 (presubmit successful).