Bug 21705 – Implement Web Workers client-side API

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

I'm going to submit a patch that implements some form of Worker/DedicatedWorker interface.

[Alexey Proskuryakov]

Created attachment 24457 [details]
proposed patch

[Oliver Hunt]

Comment on attachment 24457 [details]
proposed patch

In constructDedicatedWorker toString() may throw so you should probably exception check there

In DedicatedWorker::DedicatedWorker shouldn't 'if (!document->securityOrigin()->canAccess(SecurityOrigin::createFromString(url).get())) ' be referencing m_scriptURL ?

Is there anything here that can be tested yet?  Perhaps security tests to make sure we can't create a DedicatedWorker for an unsafe url, also

new DedicatedWorker({toString:function(){throw "Woo!!!!11!!one!";}})

and
var foo = {toString:function(){new DedicatedWorker(foo);}}
new DedicatedWorker(foo)

Although i think that should magically be limited to ~500 levels of recursion it's worth testing -- I wonder if we should however actually just require that we be given a real string -- eg. not a generic object.

other than these minor questions, r=me

[Alexey Proskuryakov]

Committed revision 37715.

(In reply to comment #2)
> In constructDedicatedWorker toString() may throw so you should probably
> exception check there

Not sure - looks like we almost never check for toString() exceptions in bindings - and the behavior in this case is not too horrible anyway (the string will be empty, so the worker will try to use calling document URL for its script, which won't parse as JS).

> In DedicatedWorker::DedicatedWorker shouldn't 'if
> (!document->securityOrigin()->canAccess(SecurityOrigin::createFromString(url).get()))
> ' be referencing m_scriptURL ?

Fixed.

> Is there anything here that can be tested yet?

The functionality is currently disabled, so tests cannot be landed - but I'll make local tests for your suggestions.