Crash in private mode after upgrade to 108 related to IDB encryption in PBM
Categories
(Core :: Storage: IndexedDB, defect, P3)
Tracking
()
People
(Reporter: onlylogout, Assigned: hsingh)
References
Details
Attachments
(1 file)
6.19 KB,
text/x-log
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0
Steps to reproduce:
- Ensure you have ublock origin installed and enabled (I suspect it should cache its files first)
- Ensure history is not enabled and the browser runs in private mode
- Upgrade the browser from 106 to 108 (fedora37 package firefox-108.0-2.fc37.x86_64)
- Launch firefox
- Observe the crash
Actual results:
So the browser crashes. The stack trace is attached in the stacktrace.log file. After a preliminary look, it seems that it's related to the newly introduced IDB encryption. Possibly the data was incorrectly migrated, since after deleting all PBM IDB data files for the ublock extension, firefox starts normally.
The crash happens here:
mozilla::dom::indexedDB::(anonymous namespace)::CreateFileBlobImpl (aId=9255, aNativeFile=<synthetic pointer>..., aDatabase=...) at /usr/src/debug/firefox-108.0-2.fc37.x86_64/dom/indexedDB/ActorsParent.cpp:5628
to me it seems to suggest that the cipher key is somehow not present for the file..
5628 MOZ_RELEASE_ASSERT(key.isSome());
I can provide the migrated IDB data, but I don't have the old unencrypted data files anymore.
Expected results:
Expected results are that the data for the extension should be properly migrated and the browser shouldn't crash :)
Reporter | ||
Comment 1•2 years ago
|
||
I didn't bold it, but I want to reiterate that after deleting the "moz-extension+++068f467a-f67b-483b-a9b8-18a82c53b2b2^privateBrowsingId=1" folder, firefox starts normally (and a new folder with the same name is created there).
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Storage: IndexedDB' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Assignee | ||
Comment 3•2 years ago
|
||
IDB encryption should be under configuration toggle. Could you please confirm if we have enabled the configuration 'dom.indexedDB.privateBrowsing.enabled' in this system ?
Reporter | ||
Comment 4•2 years ago
|
||
(In reply to Harveer Singh from comment #3)
IDB encryption should be under configuration toggle. Could you please confirm if we have enabled the configuration 'dom.indexedDB.privateBrowsing.enabled' in this system ?
I have this setting set to true (it displays as bold). However I don't remember toggling it "unprovoked", I may have toggled it (still not sure) because something didn't work in private mode.
Assignee | ||
Comment 5•2 years ago
•
|
||
So, this feature is still under development. So, I am going to put this bug in our backlog and will definitely ensure that this bug gets fixed before we officially release it.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 6•2 years ago
|
||
We have completely redesigned the IDB storage under private browsing mode. Would that be possible for you to verify the bug by running this again?
Reporter | ||
Comment 7•2 years ago
|
||
I'm afraid I'd not be able to recheck the exact scenario, I'm on Fedora 38, that version of firefox is no longer available and I don't have any old pre-upgrade data. I can only say that I'm currently using this setting and I didn't observe any problems with that.
Assignee | ||
Comment 8•2 years ago
|
||
Okay, based on your feedback and our observations. I think it's safe to close this bug now as invalid as this is not relevant in our new design. If you see the occurrence in future, please feel free to open it again.
Assignee | ||
Updated•2 years ago
|
Description
•