Closed Bug 1218756 Opened 9 years ago Closed 9 years ago

UUID regeneration seems to break indexeddb support

Categories

(WebExtensions :: Untriaged, defect)

defect
Not set
normal

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).
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
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.