Worklet: Not allowed to instantiate Worklet via Blob on file:// scheme page
Reported by
s...@cycling74.com,
Oct 23 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3247.0 Safari/537.36 Steps to reproduce the problem: 1. Open the attached "dynamicWorklet.html" via Cmd-O (Open File) which contains an embedded AudioWorklet What is the expected behavior? The AudioWorklet should instantiate without a security error, since there is no local file system access (the Worklet code is embedded inside a string in the script itself). What went wrong? Error "Not allowed to load local resource: blob:null/..." is thrown Note: when you open the same file via a local webserver, no error is thrown and the AudioWorklet instantiates without problems. Did this work before? N/A Chrome version: 64.0.3247.0 Channel: canary OS Version: OS X 10.12.6 Flash Version: For Comparison: the attached WebWorker example (InlineWebWorker.html), which uses the same method of embedding the code in a string, does not throw an error, no matter if opened via a local webserver or via Cmd-O.
,
Oct 23 2017
nhiroki@ It seems that worklet.addMoudle() doesn't work if you open the local file?
,
Oct 26 2017
Looks like GetOriginFromMap() in SecurityOrigin.cpp returns |this| for WebWorker, but not for Worklet.
// Called from SecurityOrigin::CanDisplay() via BaseFetchContext::CanRequestInternal().
bool SecurityOrigin::CanRequest(const KURL& url) const {
if (universal_access_)
return true;
if (GetOriginFromMap(url) == this) // <=== This comparison fails on Worklets
return true;
// ... snip ...
return false;
}
IIUC, in this case, GetOriginFromMap() returns a Document's SecurityOrigin instance. WebWorker shares the SecurityOrigin instance with Document for fetching scripts and |this| is the instance, so the comparison succeeds. On the other hand, Worklet uses its own SecurityOrigin instance passed from the worker thread and |this| is different from Document's SecurityOrigin, so the comparison fails.
I'm not sure what the correct behavior is yet. I'll investigate this more...
,
Oct 26 2017
This issue is not AudioWorklet-specific.
,
Jun 8 2018
,
Nov 15
Sorry, I haven't worked on this yet. Let me return this to 'available' for now. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by hongchan@chromium.org
, Oct 23 2017