dom-storage2-changed notifications not received in chrome in e10s mode

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
4 years ago
5 days ago

People

(Reporter: mozilla, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (X11; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150108202552

Steps to reproduce:

1. Subscribe the the dom-storage2-changed from an XPCOM component
2. Set or clear a local storage or session storage key from content script


Actual results:

Nothing happened


Expected results:

The observer should be called whenever the contents of DOM storage are changed.
Blocks: 516752
Component: Untriaged → DOM
Product: Firefox → Core
Is this something we should be supporting, Honza?
Flags: needinfo?(honzab.moz)
(Reporter)

Comment 2

4 years ago
I fear what Honza will say.  After all, why rewrite the whole sessionstore module to use a frame script if session storage is easily available in chrome.

Still, local storage is visible from chrome and it would be valuable to have some way of knowing when it changes.
DOM storage is minimal in what is needed for e10s.  It only does what it has to to fulfill the spec.  E.g. ff we had more content processes (per tab), then ls/ss would break.  There is e.g. no concept of syncing changes between content processes which cache the data.  So far we luckily have just a single content process.

This bug is kinda connected to it.  If this is just about sending an async message to the parent process, then we could try, but I fear there is no object to pass to the parent.  According [1] we should pass the DOM storage object.  Note that there is no representation and no data access of ss on the parent.  You can see ls content tho.

Also, the spec is stupid since it allows pile up of the events.  We already are sending up to the parent any LS updates and it already eats memory enough.  If we also send up full storageEvent's I don't think we would improve the performance here.

So I'm against doing this.

[1] https://mxr.mozilla.org/mozilla-central/source/dom/storage/DOMStorage.cpp#204
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(honzab.moz)
Resolution: --- → WONTFIX

Comment 4

2 years ago
There are addon developers who state that this change makes their addons impossible to implement. These are privacy-based addons which monitor cookie storage and instantly remove any cookie that is not currently in use in any tab. 

Seeing as having an alternative implementation for current addons is a high priority with the new addon structure, I argue this bug should not have been closed. 


I find it concerning that one person voted not to do it, and thus the entire bug was closed. It does not appear to have been the result of a discussion elsewhere, just one contributor's opinion. I would think that more people should be allowed to weigh in before such actions are taken.

Comment 5

2 years ago
I just created this account to say i really dislike the attention this got.
There are addons like Self Distructing Cookies that need to monitor LocalStorage, and i'm not exactly sure who gave the call to mark this as unresolved, you're basically taking away a feature for almost no gain, it's impossible to make those addons work with E10s without this ability.

It's making me personally frustrated because i use some of those addons which got no replacements because apparently the feature itself got removed.

I'd like a new review on this.
Since we are moving away from XPCOM based addons and migrate to WebExtensions, this bug has even less meaning.

If there is no API provided by WebExtensions for addons monitoring LocalStorage, please file bug under [1] to discuss it.

[1] https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit&component=WebExtensions%3A%20Untriaged
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.