Gracefully handle calls to IndexedDB from third-party iframes when third-party cookies are blocked
Categories
(Core :: Storage: IndexedDB, defect)
Tracking
()
People
(Reporter: liamre, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
Actual user agent: Firefox Nightly 90.0a1 (2021-04-21) (64-bit)
Visit https://beacon.schneidercorp.com/Pictometry/ViewerIPA.aspx?AppID=1051&LayerID=23951&PageTypeID=4&PageID=9973&KeyValue=16002500190 with network.cookie.cookieBehavior set to 1 (all third-party cookies blocked)
Actual results:
The page is broken due to an "Uncaught DOMException: The operation is insecure." error from the third-party iframe trying to access/read/check for IndexedDB.
Expected results:
The call to IndexedDB should be gracefully handled or ignored (not sure how this works).
In Chromium-based browsers, this page is not broken with third-party cookies blocked.
Not sure whether to file as a defect due to the fact that the site is broken, or that the behavior doesn't match Chromium, or as an enhancement because it is a request to change this behavior. Feel free to edit this if I chose wrong.
|
Reporter | |
Comment 1•5 years ago
|
||
Just realized that's not a user-agent. Here: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0
|
|
Reporter | |
Comment 2•5 years ago
|
||
Try this URL if the original one doesn't work: https://beacon.schneidercorp.com/Application.aspx?AppID=1051&LayerID=23951&PageTypeID=4&PageID=9973&KeyValue=16002500190
|
||
Comment 3•5 years ago
|
||
Thanks for filing this bug! We had some discussion in this area previously in bug 1607302 about how to address this class of problems and we got to (local, Firefox) consensus that we should address it, but things stalled somewhat on the standardization follow up. I'm going to dupe to that bug, but the reality is that it will be a few months before we can get to it because of recent turnover in engineering staff.
Description
•