157600 2016-05-11 17:23:10 -0700 WebKit fails w3c interface tests on Workers (http://w3c-test.org/workers/interfaces.worker and http://w3c-test.org/IndexedDB/interfaces.worker) 2016-06-07 18:02:38 -0700 1 1 1 Unclassified WebKit WebCore Misc. WebKit Nightly Build Unspecified Unspecified RESOLVED DUPLICATE 158446 InRadar P2 Normal --- 149117 1 beidson webkit-unassigned achristensen cdumez webkit-bug-importer oldest_to_newest 1192164 0 beidson 2016-05-11 17:23:10 -0700 Modern IDB: IDB object constructors aren't exposed on the WorkerGlobalScope I *think* fixing this is as simple as a change to WorkerGlobalScopeConstructors.idl to shadow DOMWindowConstructors.idl. Will test soon. 1192183 1 beidson 2016-05-11 18:44:39 -0700 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 1192189 2 cdumez 2016-05-11 19:15:23 -0700 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? 1192190 3 cdumez 2016-05-11 19:19:29 -0700 (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 1192195 4 beidson 2016-05-11 20:32:54 -0700 (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. 1192202 5 cdumez 2016-05-11 21:01:05 -0700 (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. 1192204 6 beidson 2016-05-11 21:05:20 -0700 (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. =/ 1192205 7 beidson 2016-05-11 21:06:31 -0700 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 1192206 8 beidson 2016-05-11 21:07:41 -0700 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. 1192234 9 cdumez 2016-05-11 22:59:26 -0700 (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. 1192320 10 beidson 2016-05-12 06:28:40 -0700 (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. :( 1199242 11 webkit-bug-importer 2016-06-04 10:20:18 -0700 <rdar://problem/26638397> 1200268 12 cdumez 2016-06-07 18:02:38 -0700 *** This bug has been marked as a duplicate of bug 158446 ***