Firefox throws DOMException error caches.keys()
Categories
(Core :: Storage: Cache API, defect)
Tracking
()
People
(Reporter: brodhead.tom, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Steps to reproduce:
Any JavaScript that includes caches.keys() will fail.
Simply run console.log(caches.keys()); in the Firefox DevTools console to see.
Actual results:
The Promise is not resolved and this error is reported:
Uncaught (in promise) DOMException: The operation is insecure.
Promise { <state>: "rejected", <reason>: DOMException }
<state>: "rejected"
<reason>: DOMException: The operation is insecure.
Expected results:
The Promise resolves with the following reported (see commentary below):
Promise {<pending>}
proto: Promise
[[PromiseState]]: "fulfilled"
[[PromiseResult]]: Array(0)
The above is what is reported in the console of the DevTools in Chromium browsers. This is consistent with the documented behavior of caches.keys(), as found here:
https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage/keys
|
||
Comment 1•5 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'DevTools::Console' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
Reporter | |
Comment 2•5 years ago
|
||
This isn't a DevTools::Console issue; it's something affecting JavaScript that can be illustrated easily in the console, which is why I supplied the example of how to reproduce it there.
How do I revert the change?
|
|
Reporter | |
Comment 3•5 years ago
|
||
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #1)
The Bugbug bot thinks this bug should belong to the 'DevTools::Console' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
See my comment above...this is a JavaScript issue. It can easily be demonstrated in the Console, which is why I described how to reproduce it there. How do I reverse the classification?
|
||
Comment 4•5 years ago
|
||
Would you have a page we can test this on? I am not able to reproduce the issue locally
|
|
Reporter | |
Comment 5•5 years ago
|
||
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #4)
Would you have a page we can test this on? I am not able to reproduce the issue locally
I've discovered that this only happens in a Private/Incognito window in Firefox, not in a standard window...my apologies for not catching this when first reporting it.
I've just reproduced it in a Private window in both the current Firefox (89) and the Firefox Developer Edition (90.0b1). It does not occur in Incognito windows in Chromium browsers.
I've created a short web page that illustrates it: https://thomasbrodhead.com/caches-keys
Open the page in a Private window in Firefox with the DevTools Console window open and you should see the error message; see the page source for the JavaScript. You should also be able to reproduce it by entering console.log(caches.keys()); in the same console.
|
|
||
Comment 6•5 years ago
|
||
Thanks for the demo page!
Let's move this to the right component so the team can look at it
|
||
Comment 7•5 years ago
|
||
Cache API isn't supported in private browsing at this time. I've filed bug 1714354 as an up-to-date bug about our plans for how to support Cache API in private browsing, which I'm duping this to. I do believe we may have some bugs open in the storage space in general (and in particular, on IndexedDB) about the exceptions we report for cases like this where we're intentionally generating a storage-access failure but where that can be confusing.
Description
•