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

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Ian Nartowicz]

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.

Comment 1

[Josh Matthews [:jdm]]

Is this something we should be supporting, Honza?

Comment 2

[Ian Nartowicz]

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.

Comment 3

[Honza Bambas (:mayhemer)]

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

Comment 4

[Terrell Kelley]

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

[HeBTeMy]

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.

Comment 6

[Honza Bambas (:mayhemer)]

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