1094257 - Worker failed to load script in new tab

Status: RESOLVED FIXED

(Core :: DOM: Workers, defect)

Description

[charles.jourdan]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20141105004006

Steps to reproduce:

I want to create a web worker using Blob. So I write :

var worker = new Worker(URL.createObjectURL(new Blob(["console.log('Hello world !!');"])));
worker.onerror = function(e){ console.error(e); };


Actual results:

An exception was thrown : Error: Failed to load script (nsresult = 0x805303f4).


Expected results:

This code should prints "Hello world !!" in the console.

Comment 1

[:Gijs (he/him)]

(In reply to charles.jourdan from comment #0)
> User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101
> Firefox/35.0
> Build ID: 20141105004006
> 
> Steps to reproduce:
> 
> I want to create a web worker using Blob. So I write :
> 
> var worker = new Worker(URL.createObjectURL(new Blob(["console.log('Hello
> world !!');"])));
> worker.onerror = function(e){ console.error(e); };
> 
> 
> Actual results:
> 
> An exception was thrown : Error: Failed to load script (nsresult =
> 0x805303f4).

FWIW, this is NS_ERROR_DOM_BAD_URI . Do other browsers support blob uris for workers?

Also, I can't reproduce with a simple testcase (see URL field). It just works and gets  me the expected console log.

Comment 2

[:Gijs (he/him)]

Huh, interestingly, clicking the link I just added breaks it (but with NS_ERROR_ILLEGAL_VALUE instead...). If I copy-paste the contents of the location bar and try again in a new tab, it works again. :-\

baku, am I right in thinking you know about our workers implementation? Any idea what's going on here?

Comment 3

[charles.jourdan]

For me your URI works. In fact I have this issue when I open manually the tab (ctrl+t), open the developper tools (ctrl+shift+k) and finally enter the previous code.

I forget to specified I'm on Aurora channel. Sorry.
I test on firefox stable version and the issue doesn't appeared.

Also I see the url generated have not the same form. On Aurora the url looks like "blob:null/{hash}" and on stable version just "blob:{hash}".

Comment 4

[Andrea Marchesini [:baku]]

I cannot reproduce the issue. Plus, I often write tests in such way.
Does it happen 100% of the times?

> Also I see the url generated have not the same form. On Aurora the url looks
> like "blob:null/{hash}" and on stable version just "blob:{hash}".

This because blob URIs use the origin of the page and probably you did your test in about:blank.
More info about this can be read in bug 1058470.

Comment 5

[:Gijs (he/him)]

(In reply to Andrea Marchesini (:baku) from comment #4)
> I cannot reproduce the issue. Plus, I often write tests in such way.
> Does it happen 100% of the times?

On current beta, on Windows, if I middle-click the link in the URL field, I get the following error:

Error: Failed to load script (nsresult = 0x80070057)

every time.

On Nightly, if I open about:home (default, initial tab), open the devtools console, and execute:

var worker = new Worker(URL.createObjectURL(new Blob(["console.log('Hello world !!');"])));
worker.onerror = function(e){ console.error(e); };

I get the same error.

If I then type 'about:blank' in the location bar, hit enter, and copy-paste the same code in the console, the code works fine. Typing about:home, enter, and trying again there yields the same error again.

Comment 6

[Andrea Marchesini [:baku]]

Ok, now I'm able to reproduce the issue. The problem is that it's not possible to create a worker from about:home or any about: page.

The reason is that the Worker fails to retrieve the baseDomain from the principal of the document:

https://mxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#4044

This happens because we try to use TLD service here:

https://mxr.mozilla.org/mozilla-central/source/caps/nsPrincipal.cpp#498

and in the end it fails here:

https://mxr.mozilla.org/mozilla-central/source/dom/base/ThirdPartyUtil.cpp#349

Comment 7

[Andrea Marchesini [:baku]]

An 'easy' fix can be to support 'about' schema (and maybe others) in WorkerPrivate.cpp#4044.
But before doing it I want to have a feedback from bz.

Comment 8

[Boris Zbarsky [:bzbarsky]]

We need the baseDomain bit because of our per-domain cap on number of workers, right?

If so, I think it would be reasonable to lump all the workers that we can't get base domain for into a single bucket for cap purposes.  But please double-check with bent.

Comment 9

[Andrea Marchesini [:baku]]

bent, can you give a comment about this issue? Thanks!

Comment 10

[Ben Turner (not reading bugmail, use the needinfo flag!)]

That sounds fine to me, maybe sicking has more of an opinion?

Comment 11

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

Seems fine to me. Are we already giving pages with chrome privileges unlimited number of workers? If not, we should.

Comment 12

[Andrea Marchesini [:baku]]

(In reply to Jonas Sicking (:sicking) from comment #11)
> Seems fine to me. Are we already giving pages with chrome privileges
> unlimited number of workers? If not, we should.

This is a separated issue. about:home doesn't have chrome privileges.

Comment 13

[Andrea Marchesini [:baku]]

Attachment: base.patch

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8518881 [details] [diff] [review]
base.patch

Why would we ever have data: here?

Also, this doesn't seem like what I proposed in comment 8...  Can you explain why this is producing the behavior we want (and what that behavior is)?

Comment 15

[Andrea Marchesini [:baku]]

> Also, this doesn't seem like what I proposed in comment 8...  Can you
> explain why this is producing the behavior we want (and what that behavior
> is)?


Correct, it's not what you proposed. What this patch does is: when the page is about:something, or data:something (Actually I have to do more tests for data:), GetBaseDomain() returns error because we try to resolve the 'something' as a TLD (top-level domain). With this page, we don't do that when the schema is 'about:' or 'data:'. Instead we return 'something' as base domain.

This fixes the issue because, having a baseDomain makes possible the creation of the worker.

Comment 16

[Boris Zbarsky [:bzbarsky]]

OK, but why do we want to make that specific to data: or about:?  Why not, for example, do it for all non-hierarchical URIs?

And do we really want to have the full worker limit per such URI?

Comment 17

[Andrea Marchesini [:baku]]

Attachment: base.patch

Comment 18

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8519959 [details] [diff] [review]
base.patch

I think you want NS_URIChainHasFlags here.

r=me with that.

Comment 19

[Andrea Marchesini [:baku]]

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=dfea0ffe9e0a

Comment 20

[Andrea Marchesini [:baku]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0270b8b0fa4c

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0270b8b0fa4c