After opening the Storage tab in Developer Tools, browser.storage.onChanged does not fire for object writes.
Categories
(WebExtensions :: Storage, defect, P2)
Tracking
(firefox144 wontfix, firefox145 wontfix, firefox146 wontfix, firefox149 verified)
People
(Reporter: nines, Assigned: rpl)
References
Details
(Whiteboard: [addons-jira])
Attachments
(2 files)
Steps to reproduce:
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0
Build ID: 20251014213342
- Load the attached extension via "about:debugging#/runtime/this-firefox".
- Click “Inspect” to open Developer Tools.
- If Developer Tools was open with the Storage tab selected, switch to another tab and reopen Developer Tools.
- Open the "example extension" options page from "about:addons".
- Press F12 on the options page to open the console.
- Click the save button on the options page and confirm that the written value is logged to the console.
- Open the Storage tab in Developer Tools.
- Reload the options page and click the save button again.
Actual results:
Nothing is logged.
Expected results:
The written value is logged to the console.
This issue persists until Developer Tools is closed once the Storage tab has been opened.
This issue does not occur when the written value is not an object.
Comment 1•5 months ago | ||
Hello,
I reproduced the issue on the latest Nightly (146.0a1/20251016214704), Beta (145.0b2/20251015090420) and Release (144.0/20251009125714) under Windows 11 and Ubuntu 24.04 LTS.
The issue occurs as described in Comment 0. Additionally, at Step (8) the browser console logs:
Sending message that cannot be cloned. Are you trying to send an XPCOM object? ConduitsChild.sys.mjs:62:20
DataCloneError: JSWindowActorParent.sendQuery: Failed to serialize message 'RunListener::Conduits' ConduitsChild.sys.mjs:62
| Assignee | ||
Comment 2•5 months ago | ||
needinfo-ing myself to look more closely into what may be the underlying issue.
Comment 3•1 month ago | ||
I think my bug 2009743 can be closed as duplicate.
I would like to mention how terrible this bug is for developers - because nobody will tell you that opening Storage tab will break storage events...
There are no errors in your addon console windows.
All you see is that suddenly your app doesn't work well anymore, and you may spend quite a lot of time finding the real cause :(
I can't believe I've managed to find the connection between broken app and Storage tab.
Note that Firefox ESR 140 is also affected.
Comment 4•1 month ago | ||
The internal ExtensionStorageIDB.notifyListeners method iterates over the list of listeners and invokes each listener, with a reference to the same object.
The devtools extension storage actor subscribes to storage changes here: https://searchfox.org/firefox-main/rev/131497bb1b747587b2b21b1abf14f44ecffad805/devtools/server/actors/resources/storage/extension-storage.js#90
Its handler deserializes StructuredCloneHolder, which by default does not keep the data. To keep it, true must be passed as a second parameter. But the devtools storage actor does not set it: https://searchfox.org/firefox-main/rev/131497bb1b747587b2b21b1abf14f44ecffad805/devtools/server/actors/resources/storage/extension-storage.js#188,191
Could that possibly be causing this bug?
Updated•1 month ago |
Updated•1 month ago |
| Assignee | ||
Comment 6•1 month ago | ||
| Assignee | ||
Comment 7•1 month ago | ||
(In reply to Rob Wu [:robwu] from comment #4)
...
Its handler deserializes StructuredCloneHolder, which by default does not keep the data. To keep it,truemust be passed as a second parameter. But the devtools storage actor does not set it: https://searchfox.org/firefox-main/rev/131497bb1b747587b2b21b1abf14f44ecffad805/devtools/server/actors/resources/storage/extension-storage.js#188,191Could that possibly be causing this bug?
Yes, that was definitely the underlying issue.
I've just attached a patch with a fix for those two deserialize calls and added a test case to the existing xpcshell test to guard the behavior from regressing (I made sure that the test fails without the fix, the values stored need to not be primitive values otherwise we would not be serialize the old and/or new value into StructuredCloneHolder insteances and the issue would not be hit).
Comment 9•1 month ago | ||
| bugherder | ||
Comment 10•1 month ago | ||
Verified as Fixed. Tested on the latest Nightly (149.0a1/20260215214423) under Windows 11 and Ubuntu 24.10.
Using the attached extension and the STR from Comment 0, I can no longer reproduce the issue. After Step (8), the written value is logged to console as expected.
Furthermore, the errors mentioned in Comment 1 are no longer appearing in the browser console after performing the STR.
Updated•1 month ago |
Description
•