Closed Bug 1302527 Opened 8 years ago Closed 7 years ago

indexedDB.open never completes when passed an options object with a `storage` property

Categories

(WebExtensions :: General, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1331618
webextensions ?

People

(Reporter: brunoaiss, Assigned: kmag)

References

Details

(Whiteboard: triaged)

Attachments

(1 file, 1 obsolete file)

Attached file Example code to show it is not working (obsolete) —
I can't successfully open an IndexedDB in background scripts in WebExtensions.

If you run try the attached script in a background page, none of the callbacks are ever called.

When running nightly debug build, I only get this logged

> [Parent 26972] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80070057: file c:/builds/moz2_slave/m-in-w32-d-0000000000000000000/build/src/dom/base/nsContentUtils.cpp, line 6068

I have no idea if that output is useful but it is the only thing I have.
As per request, I attach a near-minimalistic extension that uses IndexedDB and opening IndexedDB calls no callback.
Attachment #8790912 - Attachment is obsolete: true
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: IndexedDB not calling callbacks when initiated in background page of a WebExtension → indexedDB.open never completes when passed an options object with a `storage` property
Component: WebExtensions → DOM: IndexedDB
Product: Toolkit → Core
Summary: indexedDB.open never completes when passed an options object with a `storage` property → IndexedDB not calling callbacks when initiated in background page of a WebExtension and an object with "storage:" key is given as the second parameter
ups
Summary: IndexedDB not calling callbacks when initiated in background page of a WebExtension and an object with "storage:" key is given as the second parameter → indexedDB.open never completes when passed an options object with a `storage` property
See Also: → 1278100
Do we expect this to work, Jan?
Flags: needinfo?(jvarga)
If you use |indexedDB.open(name, { storage: "persistent" })| then indexedDB implementation sends some notifications to the chrome to show a prompt asking if the user wants to enable persistent storage for given origin. This all works correctly in normal content, but I guess WebExtensions code doesn't handle the notifications so opening of the database never completes.
The initial notification is "indexedDB-permissions-prompt".
Flags: needinfo?(jvarga)
Hi could you please see if handling the notification as comment 4 mentioned resolves your issue?
Flags: needinfo?(brunoaiss)
There's no such prompt.
Flags: needinfo?(brunoaiss)
(In reply to brunoais from comment #6)
> There's no such prompt.

Have you handled the notification "indexedDB-permissions-prompt"?
No
Anyway, is there a way to get the list of websites/hosts I handled that?
(In reply to brunoais from comment #9)
> Anyway, is there a way to get the list of websites/hosts I handled that?

Not sure if we understand each other, I was talking about an internal notification sent by indexeddb implementation through the observer service. 

Take a look at IndexedDBPromptHelper in browser/base/content/browser.js to see how it's handled there.
I don't know much how supporting code for WebExtensions is implemented, but the notification needs to be handled by the supporting code and not by web extensions.
OK, this is probably a WebExtension bug, then. We should probably just silently grant permission, based on the extension's permissions.

It's interesting that this works without the options object, though, but doesn't work with it, whether `storage` is "persistent" or "temporary".
Assignee: nobody → kmaglione+bmo
Component: DOM: IndexedDB → WebExtensions: General
Product: Core → Toolkit
{ storage: "default" } and { storage: "temporary" } should just work w/o any special handling
If it doesn't then it must be a different bug.
Could the code be dropping all URLs that does not start with "http:", "https:" or "file:"?
Hard to say, indexeddb supports other URLs, like about:home, resource:
How about "moz-extension:"? I don't mean it not supporting the schema, I mean the code deliberately dropping anything that does not conform a whitelist or a format and "moz-extension" not being on that whitelist or the hyphen being an issue.
Flags: needinfo?(jvarga)
I believe that would just throw an exception.
Flags: needinfo?(jvarga)
Priority: -- → P1
Whiteboard: triaged
webextensions: --- → ?
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: