Summary: | WebKit fails w3c interface tests on Workers (http://w3c-test.org/workers/interfaces.worker and http://w3c-test.org/IndexedDB/interfaces.worker) | ||
---|---|---|---|
Product: | WebKit | Reporter: | Brady Eidson <beidson> |
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | achristensen, cdumez, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | |||
Bug Blocks: | 149117 |
Description
Brady Eidson
2016-05-11 17:23:10 PDT
I see that all these constructors were put on WorkerGlobalScope.idl in http://trac.webkit.org/changeset/199889 For whatever reason it is not working. The conditional INDEXED_DATABASE_IN_WORKERS is enabled, and IndexedDBWorkers is enabled at runtime by default, but they still aren't showing up. I'm building with these all put in WorkerGlobalScopeConstructors.idl to see if that works... /me shrugs What is not working exactly? Clearly, they were exposed as of http://trac.webkit.org/changeset/199889 based on the layout test that I added and was passing, right? (In reply to comment #2) > What is not working exactly? > > Clearly, they were exposed as of http://trac.webkit.org/changeset/199889 > based on the layout test that I added and was passing, right? I have just confirmed that the test that I added in r199889 is not skipped and passing on the bots: storage/indexeddb/modern/workers-enable.html (In reply to comment #2) > What is not working exactly? Sorry this wasn't mentioned - most of http://w3c-test.org/IndexedDB/interfaces.worker is failing. (In reply to comment #4) > (In reply to comment #2) > > What is not working exactly? > > Sorry this wasn't mentioned - most of > http://w3c-test.org/IndexedDB/interfaces.worker is failing. I see now. Even though they are failing, I do not believe the reason they are failing is that the constructors are not exposed. They do: assert_own_property(self, this.name, "self does not have own property " + format_value(this.name)); I assume this.name is the name of the property they want to check. This ends up calling: function _assert_own_property(name) { return function(object, property_name, description) { assert(object.hasOwnProperty(property_name), name, description, "expected property ${p} missing", {p:property_name}); }; } And we get a JS error saying that 'object' is undefined. AFAICT, 'object' is self since this is what we call assert_own_property() with as 1st parameter. Still trying to figure out what this means though. (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #2) > > > What is not working exactly? > > > > Sorry this wasn't mentioned - most of > > http://w3c-test.org/IndexedDB/interfaces.worker is failing. > > I see now. Even though they are failing, I do not believe the reason they > are failing is that the constructors are not exposed. > > They do: > assert_own_property(self, this.name, "self does not have own property " + > format_value(this.name)); > > I assume this.name is the name of the property they want to check. > > This ends up calling: > function _assert_own_property(name) { > return function(object, property_name, description) > { > assert(object.hasOwnProperty(property_name), > name, description, > "expected property ${p} missing", {p:property_name}); > }; > } > > And we get a JS error saying that 'object' is undefined. > > AFAICT, 'object' is self since this is what we call assert_own_property() > with as 1st parameter. Still trying to figure out what this means though. Thanks for looking into it. I obviously misunderstood the issue, partially because the way that page is constructed is somewhat opaque. =/ Also FWIW, I'd expect at least 154 passes, as the interfaces test that works on DOMWindow has that many: http://w3c-test.org/IndexedDB/interfaces.html As a layperson in this area, it seemed to be that the difference was related to how we expose these interfaces (which I assumed meant constructors) on DOMWindow vs WorkerGlobalScope. Not sure if that will give you any tips towards the difference. (In reply to comment #8) > As a layperson in this area, it seemed to be that the difference was related > to how we expose these interfaces (which I assumed meant constructors) on > DOMWindow vs WorkerGlobalScope. > > Not sure if that will give you any tips towards the difference. I don't think the issue is really with the IDB implementation. If you look at the corresponding test for workers: http://w3c-test.org/workers/interfaces.worker We are failing most of it as well. I think the issue is with our worker support somehow. (In reply to comment #9) > (In reply to comment #8) > > As a layperson in this area, it seemed to be that the difference was related > > to how we expose these interfaces (which I assumed meant constructors) on > > DOMWindow vs WorkerGlobalScope. > > > > Not sure if that will give you any tips towards the difference. > > I don't think the issue is really with the IDB implementation. If you look > at the corresponding test for workers: > http://w3c-test.org/workers/interfaces.worker > > We are failing most of it as well. I think the issue is with our worker > support somehow. I see, so we botch these interface checks on web workers for *all* exposed objects. Yay. :( *** This bug has been marked as a duplicate of bug 158446 *** |