Bug 226637 – Worker.constructor throws an exception when the url param is an empty string

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[[e-mail]]

Steps to reproduce:

(1) Open a tab and navigate to any URL;
(2) Run the following code in the Console of Devtools:
```
new Worker("")
```
(3) Then this code would throw a SyntaxError exception.

Actual results:

This code would throw a SyntaxError exception: `SyntaxError: The string did not match the expected pattern.`

Expected results:

For EventSource.constructor, as https://html.spec.whatwg.org/multipage/server-sent-events.html#dom-eventsource says, when the URL param is an empty string, it should be parsed as a relative URL to the API's URL.
In fact, Firefox works as the spec says, and Chrome has fixed this problem following the spec nowadays too.

I think the URL script param of Worker.constructor should be parsed as a relative URL to the API's URL too.
In my test, both Chrome and Firefox would not throw the SyntaxError exception and would parse it as the relative URL when evaluating this code.

[Chris Dumez]

Created attachment 430625 [details]
Patch

[Alex Christensen]

Comment on attachment 430625 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=430625&action=review

> LayoutTests/fast/workers/worker-constructor-expected.txt:1
> +CONSOLE MESSAGE: SyntaxError: Unexpected token '<'

I saw this in Chrome.  In Firefox I see this:
Loading Worker from “http://example.com/” was blocked because of a disallowed MIME type (“text/html”).

[Chris Dumez]

(In reply to Alex Christensen from comment #2)
> Comment on attachment 430625 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=430625&action=review
> 
> > LayoutTests/fast/workers/worker-constructor-expected.txt:1
> > +CONSOLE MESSAGE: SyntaxError: Unexpected token '<'
> 
> I saw this in Chrome.  In Firefox I see this:
> Loading Worker from “http://example.com/” was blocked because of a
> disallowed MIME type (“text/html”).

Either way, the browser attempts treats the input as a relative URL and ends up trying to load the test page URL in a Worker. Looks like Blink and WebKit just ignore the fact that the response is text/html and still try to process it as a worker script, while Firefox gives up after seeing the Content-Type.

[Chris Dumez]

Created attachment 430633 [details]
Patch

[EWS]

Committed r278520 (238519@main): <https://commits.webkit.org/238519@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 430633 [details].

[Radar WebKit Bug Importer]

<rdar://problem/78898556>