943830 - Firefox could throw away form (and storage?) data for tabs earlier than URLs and Titles

Status: NEW

(Firefox :: Session Restore, enhancement)

Description

[Seb A]

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131112160018




Expected results:

(In reply to David Rajchenbach Teller [:Yoric] <needinfo? me> from comment #82)
> (In reply to Seb A from comment #80)
> > Why shouldn't Firefox throw away form data (only) for tabs immediately once
> > they are closed?  This would alleviate the problem, and could also be
> > combined with throwing away form data once pages are more than one away from
> > the current page in the history. Saving form data for the current page, plus
> > 1 backwards and 1 forwards (if there is that history) is useful, but one
> > doesn't need as much history for form data as for URLs (and Titles).
> 
> Could you file a bug with these suggestions?

OK, here it is!

Comment 1

[Mardeg]

Undoing an accidentally closed a tab with form data should still recover that data at least, but I see discarding data from more than the immediately last opened tab as reasonable.

Comment 2

[Seb A]

Those quotes were from Bug 669034.  As as this one:

(In reply to User Dderss from comment #81)
> Firefox should make
> "browser.sessionstore.max_tab_history_backwards_forwards" settings in
> "about:config" with 0 being set as default behaviour, and other figure as
> the limit.

This ("browser.sessionstore.max_tab_history_backwards_forwards") appears to be a setting that Dderss has named for the feature I have just suggested as I can't find any other reference to it.

> The issue is that even if I am not power user and I do not need deep
> backwards/forwards history within a tab, I can steel get bad experience. For
> example, one of my Google search tabs right now occupies more than 1.1 MB of
> space, according to "about:sessionstore". It has 11 backwards cashes states,
> the first of which is blank "google.co.uk" page. I look at it, and it turns
> out that Google's site stores tremendous amount of verbose styling along
> with the pictures of videos (if there are any in search results) within
> SessionStore, rather than separately in outer cache.
> 
> So those settings might need adjusting anyway.

I'm not sure whether he is referring to form data or "storage" data.  Looking at my current Firefox session in about:sessionstore, I have one tab with a google search in it occuping 1,586,122 "storage".  It has 3 previous Google search queries in the Back history (all page 1) - so this is 'worse' than Dderss' example - and the form data is only 92.  At the other end of the spectrum I have some Google result pages with no Back history where the form data is around, e.g. 83,623 and storage is 0.

But mostly I was commenting on https://bugzilla.mozilla.org/attachment.cgi?id=8338621, which shows large form data for closed tabs. If the tab is closed you almost certainly do not want the form data back.  We want to reduce the storage in sessionstore.js because it causes jank and apparently memory spikes.  In my case I have seen it stop saving and then some hours later Firefox chrome beginning to freeze and finally crash possibly as a result of too large sessions.  So anything we can do to reduce them is good, including keeping less history than for the just what is required to go back Back and Forward in a tab.

Comment 3

[Seb A]

(In reply to Mardeg from comment #1)
> Undoing an accidentally closed a tab with form data should still recover
> that data at least, but I see discarding data from more than the immediately
> last opened tab as reasonable.

Agreed, that one may want the last tab's form data back if it was accidentally closed.  So maybe a separate setting for the number of closed tabs form data to keep, default 1.

Comment 4

[Nicolas Barbulesco]

(In reply to Mardeg from comment #1)

> Undoing an accidentally closed a tab with form data should still recover
> that data at least, but I see discarding data from more than the immediately
> last opened tab as reasonable.

I agree with Madreg.

(In reply to Seb A from comment #0)

> > > Why shouldn't Firefox throw away form data (only) for tabs immediately once
> > > they are closed?  This would alleviate the problem, and could also be
> > > combined with throwing away form data once pages are more than one away from
> > > the current page in the history. Saving form data for the current page, plus
> > > 1 backwards and 1 forwards (if there is that history) is useful, but one
> > > doesn't need as much history for form data as for URLs (and Titles).

But, when the tab is not closed, the Back and Forward buttons have to keep the form data, even several steps away. This has been a standard behaviour of Web browsers for more than 10 years. Breaking this would mean unacceptable data loss.

After the tab is closed and restored, this is different.

Comment 5

[Seb A]

(In reply to Nicolas Barbulesco from comment #4)
> (In reply to Seb A from comment #0)
> 
> > > > Why shouldn't Firefox throw away form data (only) for tabs immediately once
> > > > they are closed?  This would alleviate the problem, and could also be
> > > > combined with throwing away form data once pages are more than one away from
> > > > the current page in the history. Saving form data for the current page, plus
> > > > 1 backwards and 1 forwards (if there is that history) is useful, but one
> > > > doesn't need as much history for form data as for URLs (and Titles).
> 
> But, when the tab is not closed, the Back and Forward buttons have to keep
> the form data, even several steps away. This has been a standard behaviour
> of Web browsers for more than 10 years. Breaking this would mean
> unacceptable data loss.

Consider something like a Wikipedia edit. Your form data is going to get very big pretty quickly if you have a large page that you are making edits to and previewing the results of your changes each time. On the other hand, either Wikipedia or Firefox (or both!) are doing something cleverly efficient here, because Firefox is not registering a lot for form data when you go to edit a page. It may just be saving the differences, because if I replace the text of one article with the text of another article and then check about:sessionstore the form data finally gets big. However, if I then go to preview the change (or even if I just go to about:blank in that tab), form data goes right back down. Can anyone explain this? It looks like Back and Forward form data are already not being stored in sessionstore.js (even though they are clearly being kept in memory until the next Firefox restart). This may go some way to explaining why Firefox's memory usage keeps increasing as one browses the web. Anyway, it looks that part of this bug/feature is not a session restore issue and could be looked at in memshrink.  I know you say that keepiing form data several steps away has been standard for more than 10 years but browsing habits change, the web has changed, it never worked properly with all websites, and if it causing a lot of extra memory growth maybe this should be reconsidered or adapted.  My about:blank tab (previously used to edit but not save a wikipedia page) is using 24 MB of RAM right now in about:memory.  Create a new bug/feature report for this?  I suppose the form data is such a small part of this though... I don't think I can tell how much.

The sessionstore.js size issue remains for closed tabs though.

Comment 6

[Nicolas Barbulesco]

(In reply to Seb A from comment #5)

> I know you say that keepiing form data several steps away has
> been standard for more than 10 years but browsing habits change, the web has
> changed, it never worked properly with all websites

It works properly with all Web sites made correctly. Bugzilla is a good example, Wikipedia too. The Web sites that make the users lose their info are buggy. This feature is entirely in the browser, and in all browsers. The Web site developer has nothing to do to have it work. The standard HTTP comms just make it work, automagically. When the feature does not work, it is because the Web site developer has (poorly) developed something special.