486550 - form data remains cached after browser.sessionstore.privacy_level is set to 2

Status: REOPENED

(Firefox :: Session Restore, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 (.NET CLR 3.5.30729) ID:20090305152042

Currently I run the Session Restore subgroup of Litmus against FF3.1b3 and noticed that when you change the preference browser.sessionstore.privacy_level to 2 form data is still restored once. Resetting the pref or using 0 uses the new value immediately.

Steps:
1. Set browser.sessionstore.privacy_level to 2
2. Open http://www.google.de in a new tab
3. Enter a search term into the text field
4. Close the tab
5. Restore the tab
6. Close the tab
7. Restore the tab

After step 5 the entered search term from step 3 is still restored. It will not happen after step 7. Somehow the pref change doesn't take effect immediately.

If users don't want to restore anything and feel save in flipping the pref to 2, they will remain their entered form data in the cache. Anyone can have access to form data entered in any already closed tabs (which can be restored).

Aakash, does the same also happen on other platforms?

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

I don't think undo close tab is using that preference at all, actually. Either way, hidden preference changes don't block ... this might be WFM or INVALID, though, if it turns out that it's bfcache that we're using to populate this data.

Comment 2

[Simon Bünzli]

The .privacy_level only takes effect while saving data. We'll later use whatever we get for restoring (so that extensions can still manually inject their own form data even with .privacy_level=2).

(In reply to comment #0)
> If users don't want to restore anything and feel save in flipping the pref to
> 2, they will remain their entered form data in the cache.

They'll have to either restart without restoring or clear private data to be really sure. And anyway, this pref is hidden, so you've lost any guarantee already. ;-)

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Just to note, it doesn't only occur when restoring a tab. Also when you kill (crash) and restart the browser.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Sorry for reasking blocking. That wasn't my intention but after a reload the flag wasn't updated correctly. Removing the flag for now completely.

Comment 5

[Simon Bünzli]

(In reply to comment #3)
> Just to note, it doesn't only occur when restoring a tab. Also when you kill
> (crash) and restart the browser.

Steps to Reproduce?

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Simon, I performed the following Litmus test: https://litmus.mozilla.org/show_test.cgi?id=6229

Comment 7

[Simon Bünzli]

Henrik: That test passes just fine with Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b4pre) Gecko/20090402 and I don't see why it shouldn't with your slightly older build. WORKSFORME?

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Simon, probably the test is not complete. That's why is passes fine.

Here some steps for a fresh profile which show this problem even with a latest trunk build on OS X.

1. Start Minefield with a fresh profile
2. Load about:config into the first tab and search for privacy_level
3. Switch to the second tab and enter a term into the search field
4. Switch back to tab one and change the pref to 2
5. Switch back to tab two and close the tab
6. Restore the tab e.g. by pressing Ctrl/Cmd+Shift+T

If the search field is still empty, you have to do some more steps:

7. Switch back to tab one and change the pref to 1
8. Switch back to tab two and close the tab
9. Restore the tab e.g. by pressing Ctrl/Cmd+Shift+T
10. Repeat steps 4-6

Now I definitely see restored form data even with the pref set to 2.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Oh and I forgot to say: Same happens the other way around. Going from 2 to 1 doesn't restore the form data for the first time. It's getting lost completely. See above steps (7-9) when you can see this.

Comment 10

[Simon Bünzli]

Right, this is INVALID, then: the hidden pref only applies to what is saved, not to what will be restored at a later point (cf. comment #2).

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Simon, ok so when the saving of the form data takes places? It has to be done before I switch the pref to 2 and not when closing the tab.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Hit enter too early...

Because closing a tab and restoring it afterward brings up the latest form data. But that is inconsistent with the second try of closing and restoring a tab. Then the textfield is empty.

Comment 13

[Simon Bünzli]

(In reply to comment #11)
> It has to be done before I switch the pref to 2 and not when closing the tab.

Indeed, morphing to fix this minor issue.

Comment 14

[Simon Bünzli]

Attachment: WIP