549995 - Mozilla/Firefox post 3.5 hides #windows/#tabs

Status: RESOLVED INVALID

(Firefox :: Session Restore, defect)

Description

[Robert Bradbury]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2) Gecko/20100206 Firefox/3.6
Build Identifier: Version 3.6

Prior to Firefox Version 3.5 it was possible to scan the sessionstore.js file and determine how many windows/tabs a session had open.  Post Firefox Version 3.5, when the information appears to have been moved into "places.sqlite" that is no longer true.

So (a) you have broken user scripts that can perform an analysis of session files to determine how many windows/tabs are open; (b) you have replaced them with obscure, undocumented data structures which cannot easily be interpreted by users to determine the same information; (c) you have failed to provide utilities (documented) which provide such information (i.e. how many windows/tabs are incorporated into a session).

Is it any wonder that people would move to chrome where under a simple process model a "ps -C chrome | wc -l" would yield at least the window # information?

I understand that firefox is operating under a limited framework (a single process model) -- but that does not prevent it from keeping statistics (and providing such statistics to the user) for threads consuming excess CPU.  Firefox will only be able to effectively be able to compete against chrome if it can detail who are the "bad actors" amongst a group of URLs.  Because there are bad actors -- and the individuals (programs) which can detail them will win.

Reproducible: Always

Steps to Reproduce:
1. Startup a complex firefox session
2. or load lots of pages (e.g. the first few hundred digg pages)
3. Attempt to determine # windows / # tabs open
Actual Results:  
There is no longer any file which easily details how many windows or tabs are open for a specific session.  Thus Mozilla/Firefox should provide utilities which provide such information or provide detailed documentation with respect to how it may be determined.

The individuals who said we should replace "sessionstore.js" with "places.sqlite" should be lined up in back of the Mozilla HQ and simply shot.  They provided a marginal benefit in performance in conjunction with a significant decline in the lack of user knowledge with respect to browser sessions.  Never, ever, take knowledge away from the end user -- one destroys the basis of a potentially useful relationship.  (Why whould I bother to file firefox bug reports if they seem determined to put me in the "dark"?).

There comes a point where users discard suppliers/vendors, and IMO Mozilla/Firefox is trending very close to that line.


Expected Results:  
Users should always be able to (easily) determine the number of windows/tabs involved in a session.  (Also of use would be how many sites have open connections, potentially due to Javascripts) -- i.e. what is the "load" that a mozilla/firefox session is placing on ones machine and where is it coming from?  If you cannot answer those questions one is not serving the end user.

Mozilla/firefox when it switched from sessionstore.js to places.sqlite as a storage mechanism for its session state, should have provided utilities which extracted the # windows / # tabs from such files so the end-user could determine the complexity of their session-state.

It is a flaw in the mentality of most firefox / mozilla developers that everyone runs "simple" sessions.  Simple sessions are easy.  There are people out in the real world that run complex sessions, and the skill and expertise of the developers will be judged on the basis of how such complex sessions are handled.  Do they restore reliably and hopefully quickly (both Firefox and Chrome fall down in this area).  Do they provide the ability to analyze session complexity and CPU or Network use?  (Firefox trails Chrome in this area -- and took a big step backwards in the transitation from sessionstore.js to places.sqlite without providing session state reporting software.)  I am going to tend to go with the system which provides me with the most information and the most control.  And Firefox currently (3.5+) is failing miserably in that respect.

Comment 1

[Boris Zbarsky [:bzbarsky]]

1) sessionstore.js has exactly the same information it always had, as far as I
   know.  In particular, it has the complete information needed to restore a
   session.  This information is NOT stored in places.sqlite, and I have no idea
   what gave you the idea that it is.
2) Your ps command doesn't give a correct window count for chrome, in case you
   care.

Over to the correct component for sessionstore, but this bug looks invalid to me.

Note that there is ongoing work on providing per-page resource usage information.

Comment 2

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

As Boris said, the session data is still stored in sessionstore.js and will be for the foreseeable future (bug 508740 might change that, but it's not actively being worked on). However if you turned off crash recovery, then the file won't exist until you quit (I think). The pref to enable/disable is browser.sessionstore.resume_from_crash.

(In reply to comment #0)
> It is a flaw in the mentality of most firefox / mozilla developers that
> everyone runs "simple" sessions.  Simple sessions are easy.  There are people
> out in the real world that run complex sessions, and the skill and expertise of
> the developers will be judged on the basis of how such complex sessions are
> handled.

I'm going to react to this, even though it's something that should be discussed further in bug 394492. We have data to say that most people do indeed run simple sessions (see https://testpilot.mozillalabs.com/testcases/tab-open-close/results.html). Yes there are people running complex sessions, but the majority of our users do not, and so we need to focus on them. I said much the same in bug 504998. And as pkasting said on the Chromium bug, "fixing bugs that happen when restoring 600 tabs is going to come in very low on our priority list"