indexedDB is not exposed in WorkerGlobalContext as advertised

RESOLVED DUPLICATE of bug 1147821

Status

defect
RESOLVED DUPLICATE of bug 1147821
4 years ago
4 years ago

People

(Reporter: jmareda, Unassigned)

Tracking

Details

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
Component: JavaScript: Standard Library → API: IndexedDB
OS: Windows 7 → All
Product: Core → Developer Documentation
Hardware: x86_64 → All
It is exposed on workers, but does not appears in the getOwnPropertyNames() list.  I'm not sure if thats a bug or not, though.
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.
See question in comment 2.
Flags: needinfo?(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.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(bzbarsky)
Resolution: --- → INVALID
Er, |"indexedDB" in self| will test true.
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/
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.
Flags: needinfo?(jmareda)
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.
Flags: needinfo?(jmareda)
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.
Resolution: INVALID → DUPLICATE
Duplicate of bug: 1147821
(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.
Resolution: DUPLICATE → INVALID
Resolution: INVALID → DUPLICATE
Duplicate of bug: 1147821
Ok, everything clear now, thank you for your patience.
You need to log in before you can comment on or make changes to this bug.