Currently the only way to access a secured sessionStorage item is from the domain it's been set (principal URI has to be https). This makes it impossible to save and restore those items from chrome or Firefox' SessionStore component as needed for bug 339445.

This is pretty much the same as 357323.

AFAICT bug 357323 is about file:// and possibly chrome:// documents having access to a sessionStorage of their own. This bug is about the possibility to access the sessionStorage of arbitrary https? documents. It is already possible to iterate through and modify all non-secured sessionStorage items for any domain with a system principal. Under those conditions it seems somewhat inconsistent that the same isn't possible for secured sessionStorage items (in comparison to secured cookies which can be read/written arbitrarily from chrome).

Moving to DOM: Mozilla extensions, where the rest of sessionStorage bugs rest.

Not blocking 1.9.2 on this.

I think this bug is invalidated with bug 495337.

Did anyone test this? This doesn't work in Firefox 19 and apparently never has. Access to content.sessionStorage works for non-secure pages, but for https sites it always returns length zero even when there are sessionStorage items. Clearly the principal changes have had an effect, but this bug still exists. Same sort of result getting the sessionStorage directly from the principal (getSessionStorageForPrincipal()). Returns a storage object but length is zero. Related bug 497658 for session restore of secure storage items is still open. I can't re-open this bug. Can someone else do it, or explain why I'm an idiot and this is really working?

(In reply to Ian Nartowicz from comment #7) > Did anyone test this? This doesn't work in Firefox 19 and apparently never > has. Access to content.sessionStorage works for non-secure pages, but for > https sites it always returns length zero even when there are sessionStorage > items. Clearly the principal changes have had an effect, but this bug still > exists. > > Same sort of result getting the sessionStorage directly from the principal > (getSessionStorageForPrincipal()). Returns a storage object but length is > zero. > > Related bug 497658 for session restore of secure storage items is still open. > > I can't re-open this bug. Can someone else do it, or explain why I'm an > idiot and this is really working? Can you test with build from this try run? https://tbpl.mozilla.org/?tree=Try&rev=27a6630bcafc Thanks.

The try build works, both sessionStorage and localStorage items on https pages now appear.

(In reply to Ian Nartowicz from comment #9) > The try build works, both sessionStorage and localStorage items on https > pages now appear. Thanks for checking!