Almost all forms I look at are at https:// URLs (for example, 90+% of them are Bugzilla). Session restore by default doesn't restore that form data. There is a pref to save data for https:// URLs, but that will save session cookies in addition to form data (see bug 443354), which is not acceptable. What I would like is a browser.sessionstore.privacy_level setting that will save form data, scroll position, etc for SSL sites but NOT store session cookies. Alternately, I'd like a way to set browser.sessionstore.privacy_level per site (then I could set bugzilla to restore while leaving other SSL sites as-is). The per-site solution is strictly suboptimal from my point of view, of course, since it requires a manual action on every SSL site where I care about forms, and since it doesn't help for sites that both have forms and use session cookies. I'd mark this as enhancement, except the dataloss issue with Bugzilla is a real problem for me.

We don't save/restore form data for SSL sites for fear of accidentally leaking credit card numbers, online banking information and similar sensitive information. I'm thus not sure how we could fix this bug as filed (first two sentences of comment #0). As for how to make it possible to selectively determine what should be saved and what not, that's currently left to extensions to handle. I'll post an example later on. BTW: Throwing away session cookies will currently lead to form data for pages requiring a log-in to be thrown away as well (filed as bug 345135).

What about saving textareas but not other inputs? It would seem unlikely that textareas contain credit card numbers... That said, maybe the right approach really is a per-site pref here. Or something.

This is a proof of concept extension, which emulates that additional browser.sessionstore.privacy_level value you're asking for. Does it feel right? (In reply to comment #2) > What about saving textareas but not other inputs? Without knowing what exactly we're protecting our users from, this is impossible to decide. The original spec is really quite broad and vague here. Besides, I wouldn't expect a user being able to tell the difference between a one-line textarea and an <input>. And restoring only parts of a form feels somewhat broken IMO. > That said, maybe the right approach really is a per-site pref here. Without exposing them, those are quite hard to manage, and even if we'd expose them, I'd advocate making them all-or-nothing prefs (i.e. the equivalent of the .privacy_level values 0 and 2 per domain) which wouldn't help you specifically, either.

It'd help me with restoring Bugzilla forms but not session cookies on other sites... I'll try running with the extension, thanks.

See also bug 424872.

So, instead of just testing if the scheme is https, we should do something like the following: > let channel = docShell.currentDocumentChannel; > let isSensitive = channel.QueryInterface(Ci.nsIHttpChannel) ? > channel.isNoCacheResponse() : > docShell.currentURI.schemeIs("https"); This won't work for cookies where we've got not docShell but just the cookie itself being marked as https-only, should however work fine for sites like Bugzilla.

... except that we've never directly got either a channel or a docShell where we're hitting _checkPrivacyLevel, but always a nsISHEntry or a nsIDOMWindow. Is there any way of getting the original channel's no-cache value from either of these?

(I'm coming from bug 493813) Wow, this explains what I see (and makes me sad). We make it pretty easy to restart the browser after an update is downloaded or installing an extension. Part of the rationale for making it so easy is that we're supposed to save most of the state so the browser will come back more or less as you left it. This bug changes that assumption, and there's nothing at all in the restart prompts that even hints at the fact that the browser will come back with a bunch of user data missing. Some alternatives/ideas: * Save form data except for password fields, plus a regex that matches things that look like credit card data. * Warn on quit/restart that some data will be lost * If a master password is set, save the data in question in encrypted form (this could be tricky since the SDR is not general-purpose) * Default to saving it anyway, surface an option for people who don't feel their machine is secure enough to leave data on it.

"* Default to saving it anyway, surface an option for people who don't feel their machine is secure enough to leave data on it." If I cared about the data being secure I would have an encrypted home directory and the rationale for not saving it would be non-existent.

Maybe an example what is currently being saved is attached to bug #659883 as the sessionrestore.json file. I see my gmail account address gets disclosed in the file and I just hope not my passwords/cookies (while there are some long strings looking like these). :(

Interestingly I'm noticing that filling a ticket here and causing Firefox to crash will restore the Summary field but not the other fields while I would expect that currently no field will be restored.