509626 - Sessionstore files are huge and function is slow and it still doesn't work properly

Status: RESOLVED INVALID

(Firefox :: Session Restore, defect)

Description

[Calc-Yolatuh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Sessionstore is saving too much data, too frequently. The file could grow to more than 1MB in size in limited cases.

The speed hit when trying to open Firefox with only a few tabs is more than noticeable. The impact on speed and performance when restoring many tabs (for example, the case of students during exam season), is phenomenal. With many tabs open, completely disabling the background restore is the only way to keep Firefox from bringing the whole system down. The objective of sessionstore is to save users from trying to remember what was open before any crash or close. But with the speed hit, this is a self-defeating goal at certain thresholds.

When restoring a session on a wireless connection, pages are often replaced by a gateway authentication request. This request most often changes the domain in the address bar. Despite the change in domain, Firefox will *sometimes* fail to register that a different page has been visited, thus *sometimes* losing the previous address of that tab. You can not go 'back' to it, because Firefox morphs the old address into the new address without generating a history increment. This is a timing problem, else the behavior would be 100% consistent (either 100% loss on gateway redirect or 100% success in updating the 'Back' button for each tab), per gateway of course. Different access points generate a redirect in different ways, and some should be easier to spot than others.

#It is worth noting that this last behavior has gotten worse in the FireFox 3+ line. In FireFox 2, crashing the browser with [Ctrl-Alt-Del->End Process] while it was still loading tabs, resulted in the next start safely recovering all pages (Provided one had since authenticated or moved to an unrestricted connection). In FireFox 3, even this extreme and difficult (timewise) operation does not prevent the loss of some page addresses. I assume that this load-lagging aggressiveness is a 'Feature' of the 3+ line.

Reproducible: Always

Steps to Reproduce:
1.Compare the size of sessionstore.js with the number of saved tabs.
2.Keep a log of your startup times, they generally keep getting longer. (And they get much longer, more sharply, as number of restored tabs increases.)
3.Just try using this thing at coffee shops and libraries. You will rapidly come to value the use of a second browser to log in with.
Actual Results:  
Huge files.

Slow performance and significant CPU load.

Corrupted tab history and lost pages.

Expected Results:  
Well, file size is relative, but I'd expect some positive result from caching all that data (such as faster loading of cache-defined page elements). I've seen pages load faster on browsers that store less than 0.3K/tab in the sessionstore.

From other bug reports being crossed out, and more searches and reading today, some of FireFox's more baffling speed hits are finally being ironed out. What's still missing however, is the scaling of sessionstore, and the management of rich media in tabs that are not being viewed. Steps taken to rule out flash and gif files, expose that some other culprit (most likely sessionstore) is wasting many CPU cycles on upkeep of tabs that are not changing. I expect to see NO impact on system performance when the browser is idle or being lightly used, and there is no rich media present.

This is perhaps the least wireless-friendly and least history-friendly browser. I had hoped that years of continued development and the rise of "portable computers" and "communication without wires", would finally result in a program that could be used with such technology. If nothing else, an "Enable Hotspot Check" menu item for laptop users would have been nice.

The reputation of Firefox has been slowly shifting. Among my customers are a growing number who are dissatisfied with its speed, with its corruption bugs, with its scalability, with its ability to remember data, etc.

Firefox 2 was in many ways a nearly ideal browser. Especially things like sessions and the address bar. Not once was I driven to the point of trying to report an issue, the program simply worked well enough. I directed customers to try it, and they were mostly grateful. Firefox 3 has made me angry, it has made them confused.

Firefox is no longer the primary browser on any of my PCs or virtual machines, not even under Linux. More than half of my customers have moved to other products. Please desist in offering reactionary "improvements" that are not well thought out and do not add to the user experience.

Comment 1

[Calc-Yolatuh]

Attachment: Very large files

The large volume of saved data appears to correlate with the severity of the speed hit. Some session data might be better placed in the page cache documents.

Comment 2

[Calc-Yolatuh]

Attachment: New and improved exposure of sessionrestore interface

People have been seeing this far too often

Comment 3

[Calc-Yolatuh]

Attachment: An older screenshot

This issue still exists. The focused tab had previously contained a page from the AE, like all other tabs in that window. The AE has had some VERY aggressive advertising scripts on it, which attempt to redirect the page to a new address. All non-AE tabs were redirected, not spawned. Most of them allow the user to click 'Back', but two of the tabs in this window do not.

Issue almost never happens when a redirect is tripped during normal browsing, but reaches noticeable levels on sessionrestore. This behavior is identical to the effects of many wireless access points. In such case, all tabs would have had their address changed, and roughly a quarter would have a mutated history entry (no 'Back' option)

Comment 4

[Jo Hermans]

(In reply to comment #1)
> Created an attachment (id=393683) [details]
> Very large files
> 
> The large volume of saved data appears to correlate with the severity of the
> speed hit. Some session data might be better placed in the page cache
> documents.

There should be only 1 sessionstore.js file - you're seeing multiple ones because that file could not be overwritten.

Besides - you're using a very old and very dirty profile - it still has a urlclassifier2.sqlite file, while Firefox is now using urlclassifier3.sqlite, and it's store in a different location (in local settings)

Comment 5

[Calc-Yolatuh]

See, there's the rub. This is a typical-user-worst-case. If this is what keeps happening to Firefox 2 users after their upgrade to Firefox 3, then some other behavior needs to be changed. Most home users are afraid and confused by things like creating a new profile. I brought that complaint here a while ago.

With all of these idle dismissals of "old profiles", what can be done to save end-users from themselves? I am seeing multiple sessionstore files because Firefox could not overwrite the master or clean up after itself. Sessionstore often fails at critical moments for any of a number of reasons. And most users do not have the time, knowledge or patience to fix their problems.

Why not create "New Profile" checkpoints when installing a major version update? As long as we're wasting space on an unrealistically huge modern hard drive, why not start a new profile and copy only critical data into it? This could only help the user's perception of Firefox performance.

Comment 6

[Simon Bünzli]

This isn't a bug report but a complaint which won't be handled here. Most of these issues are actually tracked in other bugs already, and if you disagree on design or community issues, please contribute in any of the mozilla newsgroups or post your feedback to http://hendrix.mozilla.org/ . Thanks.