Closed
Bug 1197475
Opened 9 years ago
Closed 9 years ago
chrome.storage.local.get Fails to Execute Callback for Missing Key.
Categories
(WebExtensions :: Untriaged, defect)
Tracking
(firefox44 fixed, firefox48 verified)
VERIFIED
FIXED
mozilla44
People
(Reporter: joshua, Assigned: billm)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
patch
|
gkrizsanits
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20150821004008
Steps to reproduce:
Reproducible on a fresh profile. Tested on version 42.0a2 (2015-08-21). Will test on the nightly version shortly.
Steps to reproduce (Setup):
1. Create a new addon with this structure:
TestAddon/
| - manifest.json
| - background.js
2. The contents of manifest.json should be:
> {
> "manifest_version": 2,
>
> "name": "TestExtension",
> "version": "0.0.1",
> "description": "An extension to test a storage error with the WebExtensions API",
>
> "permissions": [
> "storage"
> ],
>
> "background": {
> "scripts": ["background.js"]
> },
>
> "applications": {
> "gecko": {
> "id": "testextension@bugzilla.mozilla.org"
> }
> }
> }
3. The contents of background.js should be:
> console.log("Starting Extension")
> chrome.storage.local.get('testValue', function(storageResults) {
> console.log('testValue loaded.')
> console.log('Results: ' + JSON.stringify(storageResults))
> })
4. Open browser console (Ctrl+Shift+J) from Firefox window.
5. Package and install extension as per https://wiki.mozilla.org/WebExtensions#Packaging
6. Observe console.
Actual results:
The call to
> chrome.storage.local.get('testValue', callback)
errors out, and the callback is never executed.
Logs:
> Starting Extension background.js:1:1
> A promise chain failed to handle a rejection. Did you forget to '.catch', or did you forget to 'return'?
> See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise
>
> Date: Sat Aug 22 2015 16:07:03 GMT+0800 (CST)
> Full Message: ReferenceError: prop is not defined
> Full Stack: get/<@resource://gre/modules/ExtensionStorage.jsm:128:9
> Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:934:23
> this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:813:7
> Promise*this.PromiseWalker.scheduleWalkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:744:11
> this.PromiseWalker.schedulePromise@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:776:7
> Promise.prototype.then@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:451:5
> get@resource://gre/modules/ExtensionStorage.jsm:115:12
> .storage.local.get@chrome://extensions/content/ext-storage.js:16:11
> @moz-extension://f8dc7b6e-4635-434b-9ec9-ede6b4721852/background.js:2:2
Expected results:
The console should instead display:
> Starting Extension background.js:1:1
> testValue loaded. background.js:3:4
> Results: {}. background.js:4:4
Further testing seems to indicate that much of storage.local.get() is not functioning correctly. Calling it with an array of strings simply returns that array instead of an empty object or an object containing each of those strings as keys and their values.
How functional is the local storage API supposed to be at this point?
Updated•9 years ago
|
Blocks: webextensions-chrome-gaps
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → wmccloskey
Assignee | ||
Comment 2•9 years ago
|
||
This adds some missing pieces, fixes some bugs, and adds a test.
Attachment #8657911 -
Flags: review?(gkrizsanits)
Updated•9 years ago
|
Attachment #8657911 -
Flags: review?(gkrizsanits) → review+
Comment 5•9 years ago
|
||
Backed out the whole push in https://hg.mozilla.org/integration/mozilla-inbound/rev/f2e83a8b6b8e since it was intertangled and I wasn't entirely sure which part caused Mulet mochitest-5 to become permaorange with https://treeherder.mozilla.org/logviewer.html#?job_id=14545777&repo=mozilla-inbound
Comment 7•9 years ago
|
||
This landed 10 hours ago - https://hg.mozilla.org/mozilla-central/rev/4bb71e688dcd
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
status-firefox44:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Tested with recent Nightly 45.0a1 (2015-11-05), console shows "chrome.storage is undefined".
It doesn't look like it is fixed.
So far the only way I've gotten localstorage getting to work is with
```
browser.storage.local.get(null, callback)
```
```
browser.storage.local.get('key', callback)
````
and
```
browser.storage.local.get(['key1', 'key2'], callback)
```
still seem to throw the original error.
I'll have to test with a more recently nightly build.
Comment 10•9 years ago
|
||
The documentation details this feature as working:
"The only storage area Firefox supports is local."
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/storage
And this issue was marked as fixed.
These are clearly incorrect and either the information or the problem should be rectified. Currently it is impossible to develop a webextension that relies on this api.
Assignee | ||
Comment 11•9 years ago
|
||
Can one of you guys upload the extension you're testing with? I tried the one in comment 0 and it prints the expected results to the console. Also, it would help to include whatever error you're getting. I know you said it's the same message, but I suspect it might be slightly different.
Comment 12•9 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #11)
> Can one of you guys upload the extension you're testing with? I tried the
> one in comment 0 and it prints the expected results to the console. Also, it
> would help to include whatever error you're getting. I know you said it's
> the same message, but I suspect it might be slightly different.
I used the same one as the example in the first comment of this issue with a single modification.
The only difference was that I used "content_scripts" instead of "background", and its respective setting pointing to the .js file.
The error I wrote was literally copy pasted from the console, the only thing left was the file and line where the error originated, being it the first line which tries to make use of the storage api.
Assignee | ||
Comment 13•9 years ago
|
||
OK, that's bug 1197346. The storage API doesn't work in content scripts yet.
Comment 14•9 years ago
|
||
The documentation doesn't make distinction between working in background scripts or content scripts which generates this confusion, it will always convey the idea that it works fully. Thanks for checking this out
Assignee | ||
Comment 15•9 years ago
|
||
Thanks, I updated the documentation.
Comment 16•9 years ago
|
||
Created a webextension following the steps from Description: https://addons.allizom.org/en-US/firefox/addon/testwebextension/?src=ss
I was able to reproduce the initial issue on Firefox 43.0a1 (2015-08-22) under Windows 10 64-bit.
Verified fixed on Firefox 48.0a1 (2016-04-12) under Windows 10 64-bit, Mac OS X 10.11 and Ubuntu 14.04 32-bit. The expected logs are successfully displayed in Browser Console.
But I noticed an error while installing this webextension, which is thrown in Browser Console also in Firefox 43.0a1 (2015-08-22): Unable to parse JSON data for extension storage.
ExtensionStorage.jsm:107
Is this an error that we should worry about? Or it is something wrong with my webextensions?
Flags: needinfo?(wmccloskey)
Assignee | ||
Comment 17•9 years ago
|
||
That error is unfortunate but harmless.
Flags: needinfo?(wmccloskey)
Comment 18•9 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #17)
> That error is unfortunate but harmless.
Should I file a new issue for this error? Or is already tracked?
Based on Comment 16 and Comment 17, I am marking this bug as Verified.
Status: RESOLVED → VERIFIED
status-firefox48:
--- → verified
Assignee | ||
Comment 19•9 years ago
|
||
I don't think it's filed. Please file something.
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•