1241888 - Loading cross-origin worker scripts does not throw a SecurityError

Status: RESOLVED INVALID

(Core :: DOM: Workers, defect)

Description

[Mattias Buelens]

Attachment: worker-test.html

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36

Steps to reproduce:

Starting from Firefox 45, attempting to load a worker script from a different domain no longer throws a SecurityError on the Worker constructor. Instead, the worker is created and dispatches an (asynchronous) error event.

1. Launch a local web server hosting the attached webpage.
2. Navigate to the web page on the local server in Firefox 45.
3. Check the message in the developer console.


Actual results:

The developer console shows 2 messages:
* async error
* Error: Failed to load script (nsresult = 0x805303f4)

When constructing a Worker with a cross-origin script URL, a Worker instance is successfully created and dispatches an (asynchronous) error event.


Expected results:

The developer console shows 1 message:
* sync error

When constructing a Worker with a cross-origin script URL, the browser should immediately throw a SecurityError. This is the behavior in Firefox 44 or lower, as well in many other major browsers (Chrome, IE, Edge,...).

Comment 1

[Mattias Buelens]

In an ideal world, Firefox would properly implement cross-origin worker script loading and this would be a non-issue, but until then authors need to implement a fall back themselves. For no apparent reason, Firefox 45 seems to deviate from other browsers and previous Firefox versions by dispatching an asynchronous error event rather than synchronously throwing a error.

In other browsers, authors could catch the SecurityError and then fall back to loading the worker script file with cross-origin XHR and constructing the worker with a blob URL. However in Firefox 45, the worker constructor does not throw and instead authors must asynchronously handle the error event. The dispatched error event is also not readily distinguishable from an 'actual' worker error. This makes it much more difficult for authors to detect if and when the fall back should be triggered.

Comment 2

[Mattias Buelens]

I seems to have forgot to mention that this was tested on Firefox 45.0a2 (2016-01-21). My apologies.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Did ScriptLoader.cpp get converted to AsyncOpen2?

Comment 4

[Loic]

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7d5a2743cc47f60e08dcd115e10f0130862eb5df&tochange=6c6b3811aeb7472cb0de572ce1a456d07756be9a

Comment 5

[Andrea Marchesini [:baku]]

(In reply to Ben Kelly [:bkelly] from comment #3)
> Did ScriptLoader.cpp get converted to AsyncOpen2?

Yes. And this is the reason why we have this issue. It's a known thing. NI Jonas to have a feedback.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This was an intentional change. We checked with google and they also preferred to do security checks asynchronously.

Generally speaking it's a bad idea to have APIs which can fail both synchronously and asynchronously. This way you only have to watch for error events rather than for both error events and exceptions.

The spec has been updated to match this new behavior: https://github.com/whatwg/html/issues/337

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

See also https://github.com/whatwg/fetch/issues/161

Comment 8

[YF (Yang)]

per https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla#Resolving_bugs_as_INVALID

Comment 9

[Mattias Buelens]

Thank you for the quick response. After reading up on the referenced spec changes, it does indeed make sense to handle all security policy violations asynchronously.

Since this is now in the spec, I will have to implement a more robust fall back that also handles asynchronous failures. For example, I could make the worker post an initial 'ready' message as soon as it is running and ready to receive messages:
* If the main script receives an error event before it receives the 'ready' message, then I can assume that the worker failed to load and I should fall back to XHR + blob worker.
* If an error event is received after the 'ready' message, then I can be sure that the worker failed during execution and I should handle it as a script error.

Does this seem like a reasonable solution to you, or am I missing something?

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yup, that seems reasonable. It's a bit of a bummer that there's nothing like a 'load' event or a 'ready' event. But like you point out that can be implemented in application code.

Comment 11

[Mattias Buelens]

A 'load' event would be nice indeed, but for now I'll just make it work in application code. Thanks for your input!

Comment 12

[Kohei Yoshino]

Posted the site compatibility doc: https://www.fxsitecompat.com/en-CA/docs/2016/loading-cross-origin-worker-no-longer-throws-worker-in-sandboxed-iframe-will-fail/