Bug 67978 – WebWorkers fail with document.domain set when accessing from subdomain

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore JavaScript

[Dylan]

I am currently running into issues with running WebWorkers on Chrome
when document.domain is set, this is not failing in Firefox.

I am receiving the following error:
"SECURITY_ERR: DOM Exception 18"
DOMException, code: 18 in Chrome

I am currently running Chrome v13.0.782.220.

Repro:
- Set document.domain="domain.com" while visiting a "subdomain.domain.com"
- Init web worker

ER:
- Worker is initialized

AR:
"SECURITY_ERR: DOM Exception 18"
DOMException, code: 18 in Chrome

[Alexey Proskuryakov]

Does this also happen in Safari? Can you provide a test case to reproduce this?

[Andrew Wilson]

According to an email conversation with the reporter, this happens in both Chromium and Safari. I'm guessing our logic in AbstractWorker::resolveUrl() is to blame - specifically:

   if (!scriptExecutionContext()->securityOrigin()->canAccess(SecurityOrigin::create(scriptURL).get())) {                                                     
        ec = SECURITY_ERR;                                                      
        return KURL();                                                          
    }             

Not sure why securityOrigin()->canAccess() would return false in this case.

Agreed that it'd be nice to have source code for a fail case.

[Adam Barth]

>    if (!scriptExecutionContext()->securityOrigin()->canAccess(SecurityOrigin::create(scriptURL).get())) {                                                     

Whenever you see this sort of code, you probably want to call canRequest instead.

[Josh Vermaire]

We are having the same issue. Use case is as follows:
We're on a subdomain of domain.com

We set:
document.domain = "domain.com"

Later create any new worker:
worker = new Worker('worker.js')

Error returns in both Chrome and Safari: SECURITY_ERR: DOM Exception 18

Works as expected for www.domain.com.

[Adam Barth]

Will fix.

[Adam Barth]

Created attachment 113936 [details]
Patch

[Josh Vermaire]

(In reply to comment #6)
> Created an attachment (id=113936) [details]
> Patch

Thanks Adam. Is there any way to implement this into our app so that users get the functionality today?

[Adam Barth]

> Thanks Adam. Is there any way to implement this into our app so that users get the functionality today?

I'm not 100% sure I understand your question, but you'll likely need to wait until whatever kind of WebKit you're using updates past the revision when this patch lands.  If you're providing your own version of WebKit, you can control when that happens.  If someone else is providing the WebKit (e.g., iOS), then you'll need to wait for your provider to update.

[WebKit Review Bot]

Comment on attachment 113936 [details]
Patch

Clearing flags on attachment: 113936

Committed r99505: <http://trac.webkit.org/changeset/99505>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Dylan]

Just an FYI, I was able to workaround this in the mean time by initializing my worker before setting document.domain.

(In reply to comment #7)
> (In reply to comment #6)
> > Created an attachment (id=113936) [details] [details]
> > Patch
> 
> Thanks Adam. Is there any way to implement this into our app so that users get the functionality today?