Expose events in workers as per latest DOM specification

Expose events in workers as per latest DOM specification

Expose events in workers as per latest DOM specification:
https://github.com/whatwg/dom/commit/0f69e7175dcae9edffa636bb213991330d225bf3

This CL exposes Event, CustomEvent and EventTarget to Workers and not only
in the primary global scope (Window), as per the latest DOM specification.

Firefox 29 exposes both Event and EventTarget to workers but not CustomEvent
(known bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1003432).
IE11 exposes Event only to workers.

R=arv@chromium.org, tkent@chromium.org
BUG=370011
TEST=webexposed/global-constructors-listing-dedicated-worker.html
TEST=webexposed/global-constructors-listing-shared-worker.html

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

[eseidel, 2014-05-05 15:28:50]

Woh.  So does this now mean that event code has to be thread-safe?

[Inactive, 2014-05-05 15:50:09]

On 2014/05/05 15:28:50, eseidel wrote:
> Woh.  So does this now mean that event code has to be thread-safe?

The WorkerGlobalScope IDL interface already inherits EventTarget so workers
could already use the EventTarget API. My patch merely exposes an "EventTarget"
property on WorkerGlobalScope.

Regarding the Event interface. Previously, workers could already create events
using:
var event = document.createEvent("Events");
event.initEvent("foo", false, false);

Which is old fashioned. Now, an "Event" property will be exposed on
WorkerGlobalScope and workers will be able to construct an Event using its
constructor:
var event = new Event('foo');

Which is the newer way of doing the same thing.

However, I don't believe my patch adds anything that would require additional
thread safety. All the functionality (creating and dispatching events) was
already there before my CL. Let me know I am missing something.

[eseidel, 2014-05-05 18:02:24]

lgtm

[commit-bot: I haz the power, 2014-05-05 18:02:40]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/262173006/1

[commit-bot: I haz the power, 2014-05-05 18:14:53]

Change committed as 173328

[arv (Not doing code reviews), 2014-05-06 17:00:01]

LGTM

[esprehn, 2014-05-06 17:05:53]

On 2014/05/05 15:50:09, Chris Dumez wrote:
> On 2014/05/05 15:28:50, eseidel wrote:
> > Woh.  So does this now mean that event code has to be thread-safe?
> 
> The WorkerGlobalScope IDL interface already inherits EventTarget so workers
> could already use the EventTarget API. My patch merely exposes an
"EventTarget"
> property on WorkerGlobalScope.
> 
> Regarding the Event interface. Previously, workers could already create events
> using:
> var event = document.createEvent("Events");
> event.initEvent("foo", false, false);
> 

I don't think this is correct, |document| was never exposed to workers, it's
definitely not thread safe.

[Inactive, 2014-05-06 17:32:33]

On 2014/05/06 17:05:53, esprehn wrote:
> On 2014/05/05 15:50:09, Chris Dumez wrote:
> > On 2014/05/05 15:28:50, eseidel wrote:
> > > Woh.  So does this now mean that event code has to be thread-safe?
> > 
> > The WorkerGlobalScope IDL interface already inherits EventTarget so workers
> > could already use the EventTarget API. My patch merely exposes an
> "EventTarget"
> > property on WorkerGlobalScope.
> > 
> > Regarding the Event interface. Previously, workers could already create
events
> > using:
> > var event = document.createEvent("Events");
> > event.initEvent("foo", false, false);
> > 
> 
> I don't think this is correct, |document| was never exposed to workers, it's
> definitely not thread safe.

You are right, sorry my bad (I did a grep in fast/workers and found matches but
they were not in actual worker scripts). So this CL now allows workers to create
events using:
var event = new Event('foo');

Is this a problem?

[tkent, 2014-05-07 00:12:38]

On 2014/05/06 17:32:33, Chris Dumez wrote:
> Is this a problem?

I'm afraid so.
At a first glance, I found
ASSERT(!NoEventDispatchAssertion::isEventDispatchForbidden()) in
EventTarget::fireEventListeners is bogus now.  There might be other problems.

[Inactive, 2014-05-07 13:37:58]

A revert of this CL has been created in
https://codereview.chromium.org/267363003/ by ch.dumez@samsung.com.

The reason for reverting is: This may be causing issues with thread safety. I am
reverting until I get a chance to investigate..