Bug 100136

Summary:

[GTK] fast/files/workers/worker-apply-blob-url-to-xhr.html is failing

Product:

WebKit

Reporter:

Zan Dobersek <zan>

Component:

WebKitGTK

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED DUPLICATE

Severity:

Normal

CC:

barraclough, ggaren

Priority:

Keywords:

Gtk, LayoutTestFailure

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
Test case	none

Zan Dobersek

Reported 2012-10-23 09:25:41 PDT

The test fails with the following error output: Received error from worker: TypeError: 'undefined' is not a function (evaluating 'URL.createObjectURL(file)')

Attachments
Test case (3.21 KB, patch) 2012-10-24 08:33 PDT, Zan Dobersek	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Zan Dobersek

Comment 1 2012-10-23 11:01:05 PDT

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

Zan Dobersek

Comment 2 2012-10-23 11:01:56 PDT

CC-ing JSC gurus that probably have a bit more clue about what's causing this.

Geoffrey Garen

Comment 3 2012-10-23 15:12:04 PDT

I believe URL.createObjectURL has a thread safety problem.

Zan Dobersek

Comment 4 2012-10-24 08:33:31 PDT

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.

Zan Dobersek

Comment 5 2012-10-30 04:34:55 PDT

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?

Zan Dobersek

Comment 6 2012-11-01 02:40:42 PDT

*** This bug has been marked as a duplicate of bug 99178 ***

Note You need to log in before you can comment on or make changes to this bug.