The test fails with the following error output: Received error from worker: TypeError: 'undefined' is not a function (evaluating 'URL.createObjectURL(file)')
The test passes when run alone but fails if the fast/files/workers/inline-worker-via-blob-url.html test preceeds it. Describing it pretty simplified, when URL.createObjectURL gets first accessed in fast/files/workers/inline-worker-via-blob-url.html, the JSDOMURLConstructorTable has its entries set up[1] when JSDOMURLConstructor::getOwnPropertySlot is called and the 'createObjectURL' PropertyName returns the proper hash entry. In fast/files/workers/worker-apply-blob-url-to-xhr.html, URL.createObjectURL is accessed inside a worker context, but the PropertyName used then has a StringImpl object, returned by publicName(), that's not pointing to the key of the appropriate hash entry[2]. Because of that the property is not found and the test fails. The test also fails when run alone if URL.createObjectURL is accessed from the document context before the worker is started and URL.createObjectURL is accessed from that context. [1] http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/Lookup.cpp#L28 [2] http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/Lookup.h#L209
CC-ing JSC gurus that probably have a bit more clue about what's causing this.
I believe URL.createObjectURL has a thread safety problem.
Created attachment 170405 [details] Test case The test illustrates what is expected and the failure shows this at the moment doesn't work. It also includes other constructors like FileReader (with the EMPTY, LOADING and DONE properties) and a few typed arrays (with their BYTES_PER_ELEMENT property). The test runs OK in Chromium and also works OK in Firefox for the constructors that are present in the worker context.
The main issue here is that the constructor hash table is static, i.e. the same hash table is being used despite different JSGlobalData objects connected to different contexts. All the IDL interfaces indirectly tested in the test case have the JSNoStaticTables attribute and are using DOMObjectHashTableMap to provide JSGlobalData-specific prototype and 'main' hash tables. Should the constructor tables use DOMObjectHashTableMap as well?
*** This bug has been marked as a duplicate of bug 99178 ***