Closed
Bug 1218756
Opened 9 years ago
Closed 9 years ago
UUID regeneration seems to break indexeddb support
Categories
(WebExtensions :: Untriaged, defect)
WebExtensions
Untriaged
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1208874
People
(Reporter: evangelion87d, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36 Steps to reproduce: Simply restart the browser. Actual results: My extension's UUID changes and this causes that my extension's indexeddb functions do not find the old database anymore and create a new one everytime. Expected results: My extension consists in a toolbar button that opens a new tab with my extension's index.html file (its path is acquired by "chrome.extension.getURL("index.html");"). Everything works well but there is an issue with the indexeddb database: when I restart Firefox my index.html get a new UUID and so its URI changes and this causes that the indexeddb functions do not find the old database anymore. This issue does not happen if I close the tab with index.html and try to reopen it later, since the UUID is the same (until I restart the browser).
Comment 1•9 years ago
|
||
While I didn't test this and hence cannot confirm, my impression is that the current way of generating resource aliases (via random UUID) indeed breaks both indexeddb and localStorage because the "host name" changes on each run.
Version: 44 Branch → Trunk
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•