1228347 - indexedDB is not exposed in WorkerGlobalContext as advertised

Status: RESOLVED DUPLICATE of bug 1147821

(Developer Documentation Graveyard :: API: IndexedDB, defect)

Description

[Jakub Mareda]

In article about [indexedDB](https://developer.mozilla.org/en-US/docs/Web/API/IDBEnvironment/indexedDB) this approach is advertised, presumably for both workers and GUI thread:

    var DBOpenRequest = self.indexedDB.open("toDoList");

This does not work in web workers, `indexedDB` is not defined in `self`. Although some `IDB...` properties are exposed in workers, they can't be used for anything.

See this question: http://stackoverflow.com/q/33907201/607407

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

It is exposed on workers, but does not appears in the getOwnPropertyNames() list.  I'm not sure if thats a bug or not, though.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Boris, should the self.indexedDB attribute be listed in the getOwnPropertyNames(self) output in the linked stackoverflow page in comment 0?  That attribute is defined on IDBEnvironment which WorkerGlobalScope implements.

I checked using http://mozilla.pettay.fi/workerconsole/ and confirmed that self.indexedDB is defined and works, though.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

See question in comment 2.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Per spec, the property is on WorkerGlobalScope.prototype, which is on the proto chain of "self".

So |indexedDB in self| will test true, but self.hasOwnProperty("indexedDB") will test false.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Er, |"indexedDB" in self| will test true.

Comment 6

[Jakub Mareda]

This was changed to invalid but the feature is not working. I don't think people who close issues instead of testing and fixing them are helpful for Firefox community. 

Here is the test case you should've created: https://jsfiddle.net/fuj7koog/1/

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

Check this site instead:

  http://mozilla.pettay.fi/workerconsole/

The jsfiddle is failing on older firefox versions (42 and earlier), but that is unrelated to IDB on workers.  It is probably an interaction with the sandbox iframe jsfiddle is using.

Comment 8

[Jakub Mareda]

Well, it's not a jsFiddle bug, one way or another - jsFiddle sends the javascript data unaltered - it's not even possible for it to clear any variable in the worker.

The problem must be that issue only happens sometimes, such as in the jsFiddle (maybe iframes are indeed related). That doesn't make it non-issue. The user who posted relevant question had problems too and he also used version above 37.

So what I see now is that we have some function that works in your plain test case, but not in other people's work.

Comment 9

[Boris Zbarsky [:bzbarsky]]

I just tried that jsfiddle testcase in a Firefox nightly build.  I get the following console logs:

  WORKER: Worker ready for data.
  indexedDB global variable:  [object IDBFactory]
  indexedDB in WorkerGlobalScope.prototype:
    'indexedDB' getter called on an object that does not implement interface
     WorkerGlobalScope.
  self.indexedDB:  [object IDBFactory]
  indexedDB in self => true

this is all as-expected, including the exception, since the getter expects an interface instance as "this", not the prototype object.

I do see that in Firefox 42, on the same testcase, null is returned for self.indexedDB and the indexedDB global var.  In a 43 beta, though, behavior is the same as nightly.

I did check, and this is in fact a restriction related to sandboxed iframes (which jsfiddle does use).  This restriction was lifted in Firefox 43, except in cases in which third-party cookies are disabled.  See bug 1147821, of which I guess this is a duplicate.

One last comment on jsfiddle.  "it's not even possible for it to clear any variable in the worker" is not quite true, given that it's running the worker in a pretty specific environment: http, not https, and sandboxed.  Some APIs will behave differently in that environment, and some will simply not be available.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Jakub Mareda from comment #8)
> Well, it's not a jsFiddle bug, one way or another - jsFiddle sends the
> javascript data unaltered - it's not even possible for it to clear any
> variable in the worker.

I replied in SO further.  We explicitly blocked IDB in sandbox iframes completely prior to FF42.  See bug 1176434.  We then made some further changes in FF43 which fixed it for workers in sandbox iframes.

> The problem must be that issue only happens sometimes, such as in the
> jsFiddle (maybe iframes are indeed related). That doesn't make it non-issue.
> The user who posted relevant question had problems too and he also used
> version above 37.

If you look at the initial question it says Firefox OS 1.x.  That is gecko 30 and older.  He then in the comment to your answer says he tried Firefox OS 2.2 and it worked.

> So what I see now is that we have some function that works in your plain
> test case, but not in other people's work.

What do you want us to do here?  The jsfiddle works in FF43+.  In 2 weeks this will become the default firefox release version.

Comment 12

[Jakub Mareda]

Ok, everything clear now, thank you for your patience.