navigator.storage.persist() returns false in chrome extensions
Reported by
peter.m....@gmail.com,
Apr 5 2018
|
|||||||
Issue descriptionChrome Version : 65.0.3325.181 OS Version: OS X 10.13.2 URLs (if applicable) : any url What steps will reproduce the problem? 1. Clone this repo and load it as an unpacked extension https://github.com/mrcoles/test-chrome-extension-persist (it requests `storage` and `unlimitedStorage`) 2. Run it 3. The popup will show the result of `navigator.storage.persist()` What is the expected result? I expect it to say, "has persist? true" What happens instead of that? It says, "has persist? false" Please provide any additional information below. Attach a screenshot if possible. I can’t tell from any resources online if this is an issue or not. I was trying to find out if I could expect IndexedDB data to be persistent or not. I wonder if it ends up being persistent as a side effect of having `unlimitedStorage` set? Below is a link to the closest bug that I could find, but it’s listed under Blink>Storage>Quota and I feel like this needs attention in Platform>Extensions. https://bugs.chromium.org/p/chromium/issues/detail?id=680392&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort= UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
,
Apr 10 2018
Able to reproduce the issue on reported chrome version 65.0.3325.181 and on the latest chrome version 67.0.3390.0 using Windows-10, Mac 10.12.6 and Ubuntu 14.04. As the issue is seen from M63(63.0.3228.0) considering it as non-regression and marking it as Untriaged. Note: From M63 version# 63.0.3228.0 and older builds seen different behaviour, please find attached for the same. Thanks!
,
Apr 13 2018
Interesting. pwnall@, what's your take on this? Any reason to not allow extensions (possibly only those with unlimitedStorage permission) be granted access to persistent storage?
,
Apr 13 2018
I think all extensions should get access to persistent storage. There shouldn't be any incentive for them to use chrome.storage APIs when the Web Platform APIs will do. unlimitedStorage should decide how much storage extensions do, and I think that's already happening. Happy to review a CL, or let us know if you want us to look into it.
,
Apr 13 2018
I'd agree with that. I have no idea where in the code something like this would live. If you have a few pointers, I'm happy to whip up a CL, or else happy to review from the extensions side if you want to take it on!
,
Apr 13 2018
Putting this on our radar.
,
Apr 25 2018
DurableStoragePermissionContext::DecidePermission might be the place to toss in a check for this
,
Apr 25 2018
Also, the antithesis of this bug: issue 521077 "Don't grant extensions durable storage permission" We should probably resolve one or the other as WontFix
,
Apr 25 2018
Heh, fun. I think gating this on the unlimitedStorage permission is reasonable. The reason highlighted in issue 521077 seemed to basically be "extensions can use unlimitedStorage, so don't need durable storage", but I think instead it could be "extensions shouldn't request durable storage in the same way as sites". That's my $0.02, but I don't know enough about persistent storage to know if there's a reason extensions shouldn't be allowed to use it. Any particular harm? pwnall@, given this is leaning more into storage areas, I'm optimistically hoping it's something you'll have bandwidth for. :) If not, let me know, and we can figure something out!
,
Aug 3
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by krajshree@chromium.org
, Apr 6 2018