Closed
Bug 1302527
Opened 8 years ago
Closed 8 years ago
indexedDB.open never completes when passed an options object with a `storage` property
Categories
(WebExtensions :: General, defect, P1)
WebExtensions
General
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1331618
webextensions | ? |
People
(Reporter: brunoaiss, Assigned: kmag)
References
Details
(Whiteboard: triaged)
Attachments
(1 file, 1 obsolete file)
(deleted),
application/force-download
|
Details |
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
Assignee | ||
Updated•8 years ago
|
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
Assignee | ||
Updated•8 years ago
|
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
Comment 4•8 years ago
|
||
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)
Comment 5•8 years ago
|
||
Hi could you please see if handling the notification as comment 4 mentioned resolves your issue?
Flags: needinfo?(brunoaiss)
Comment 7•8 years ago
|
||
(In reply to brunoais from comment #6)
> There's no such prompt.
Have you handled the notification "indexedDB-permissions-prompt"?
Anyway, is there a way to get the list of websites/hosts I handled that?
Comment 10•8 years ago
|
||
(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.
Comment 11•8 years ago
|
||
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.
Assignee | ||
Comment 12•8 years ago
|
||
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
Comment 13•8 years ago
|
||
{ storage: "default" } and { storage: "temporary" } should just work w/o any special handling
If it doesn't then it must be a different bug.
Reporter | ||
Comment 14•8 years ago
|
||
Could the code be dropping all URLs that does not start with "http:", "https:" or "file:"?
Comment 15•8 years ago
|
||
Hard to say, indexeddb supports other URLs, like about:home, resource:
Reporter | ||
Comment 16•8 years ago
|
||
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)
Updated•8 years ago
|
Priority: -- → P1
Whiteboard: triaged
Updated•8 years ago
|
webextensions: --- → ?
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•