726455 - sessionStorage is not restored on undo-close tab on sites with changed document.domain

Status: NEW

(Firefox :: Session Restore, defect)

Description

[Tomasz P. Szynalski]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Build ID: 20120208060813

Steps to reproduce:

1. Go to http://ipa.typeit.org/session.htm - this page uses document.domain to change the origin to 'typeit.org'.
2. Type in 'foo' into the 'sessionStorage' field.
3. Reload page to make sure the page says 'sessionStorage: foo'. 'foo' is now stored in sessionStorage.
4. Close tab.
5. Undo-close tab. (Ctrl+Shift+T)


Actual results:

sessionStorage is empty.


Expected results:

sessionStorage should contain what it contained when the tab was closed.

When the 'document.domain = "typeit.org";' line is removed from the page, Firefox properly saves the contents of sessionStorage and restores it when you undo-close a tab. The same should happen when a page's origin is set to a different domain than its hostname.

This bug prevents me from using document.domain on www.typeit.org to create a common temporary storage space for a number of foreign-language editors (each editor has its own subdomain, e.g. french.typeit.org, spanish.typeit.org, etc.). If I try to set the document.domain to 'typeit.org', Firefox will no longer restore user data if a user accidentally closes the tab.

Comment 1

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Session Restore gets the domain of the page and gets & saves session storage for that.

The relevant parts of _serializeSessionStorage
(https://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/src/nsSessionStore.js#2002):
> uri = aHistory.getEntryAtIndex(i, false).URI
> principal = SecuritySvc.getCodebasePrincipal(uri);
> storage = aDocShell.getSessionStorageForPrincipal(principal, "", false);

Boris, is there a better way to get storage data and account for document.domain? I'm assuming we wouldn't get a principal for the value of document.domain (instead of uri).

After changing serialize, we would need to fix deserialize too - it also uses the url we saved, not document.domain...

Comment 2

[Boris Zbarsky [:bzbarsky]]

> principal = SecuritySvc.getCodebasePrincipal(uri);

Yeah, that'll fail for more than document.domain.

You have an actual nsISHEntry, right?  I wonder whether we could just store the principal in the SHEntry.  We already do in some cases (the "owner"), but not in all cases...