...the same way as what we have in the main thread.
That way we can start using the real DOM events in workers without any hacks in them.
Created attachment 767736 [details] [diff] [review]
This is regression risky, but I don't know how else to deal with this.
Eventually all the events should be DOM events ofc.
I wouldn't worry too much about this breaking things. I don't think these interfaceobjects are used terribly much. Though it would be good to land this early in a cycle and then hope that a lot of the followup patches to use more xpcom Events in workers can land in the same cycle.
I switched back the doc flag as there much more doc needed for this bug: we need to actually document WorkerEvent and co :-)
BTW, I wasn't able to find the spec where these interfaces are specified. Anybody knows about it?
Thanks in advance.
We shouldn't document the Worker* variants, IMO. They're broken versions of the Event interfaces, only exposed to workers; they're being renamed because we're going to implement the correct main-thread implementations to workers.
There are Worker* events also in the main thread, in case events are dispatched to main thread Worker.
But yes, all the Worker* events are just temporary and we're trying to get rid of them asap.
So I switch back to dev-doc-complete :-) Thanks for the explanation!
I think the site-compat doc should explain that the change is temporary.
Fixed the description in the compatibility doc.
Can you please point me to the bug that undoes the change?
Filed bug 921485.
The temporary "Worker" prefix was removed again by bug 928312.
(In reply to Masatoshi Kimura [:emk] from comment #14)
> The temporary "Worker" prefix was removed again by bug 928312.
OK, will add a note to the 28 compat doc :)