Bug 157600 – WebKit fails w3c interface tests on Workers (http://w3c-test.org/workers/interfaces.worker and http://w3c-test.org/IndexedDB/interfaces.worker)

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebCore Misc.

[Brady Eidson]

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.

[Brady Eidson]

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

[Chris Dumez]

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?

[Chris Dumez]

(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

[Brady Eidson]

(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.

[Chris Dumez]

(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.

[Brady Eidson]

(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. =/

[Brady Eidson]

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

[Brady Eidson]

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.

[Chris Dumez]

(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.

[Brady Eidson]

(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.

:(

[Radar WebKit Bug Importer]

<rdar://problem/26638397>

[Chris Dumez]

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