Closed Bug 561149 Opened 14 years ago Closed 13 years ago

Startup issue: Delay loading of background tabs (BarTab-like behavior) when restoring session

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: limi, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: meta) 

(Note: this is filed as a meta bug as part of the “Paper Cut” bugs since we assume that there are multiple existing bugs related to this behavior. Please make them block this bug.)

To reproduce:
1. Shut down your browser with session restore enabled and 200 tabs open.
2. Start the browser again.
3. Enjoy your computer slowing to a halt for the next 2 minutes, network depending.

Recommendation:
We should include the same behavior as the BarTab extension:
https://addons.mozilla.org/en-US/firefox/addon/67651/

Delayed loading of tabs on session restore means faster startup + less memory used until you need the tab.
So bug 514490 wasn't enough as a fix ? You now have 1 high priority tab, and 199 medium priorities (if there all in 1 window). Maybe we should only use a limited number at medium priority (the first 10 for instance). The rest can be low priority. This was also menioned in <https://wiki.mozilla.org/Firefox/Projects/Per_Tab_Network_Prioritization>, but not implemented.

Or maybe bug 257453 ?

Does BarTab use other tricks ?
(In reply to comment #1)
> So bug 514490 wasn't enough as a fix ? You now have 1 high priority tab, and
> 199 medium priorities (if there all in 1 window). Maybe we should only use a
> limited number at medium priority (the first 10 for instance). The rest can be
> low priority. This was also menioned in
> <https://wiki.mozilla.org/Firefox/Projects/Per_Tab_Network_Prioritization>, but
> not implemented.

Network prioritization is one issue and certainly an important one. But by far the biggest problem when restoring a session with lots of tabs (or alternatively opening many tabs at a time from e.g. a bookmark folder) is the rendering. It just eats a lot of CPU cycles and memory, thus making the browser unusable for the first few seconds. Which is typically when you want to use the browser -- right after you started it up.

> Or maybe bug 257453 ?

Bug 257453 mostly describes what the "Load Tabs Progressively" add-on does: only load X number of tabs at a time. This helps with both the network and the rendering as it spreads the load over greater time. It's not as radical as BarTab.

> Does BarTab use other tricks ?

Yes. It actually prevents tabs that aren't needed from being loaded. When the nsISessionStore service restores tabs, BarTab will let it restore the browser object and the attached history, but not load the page itself. You can configure it to do the same when you open a link in a new background tab. The loading will eventually take place when you visit the tab (though other mechanisms would surely work). The initial idea was to reduce the number of CPU cycles for browser (re)starts, but it turned out it also helps with memory (ok, not too surprising I guess).

Some BarTab users have also reported other interesting usability side effects:

* A video or audio site won't start playing annoying sounds through your speakers when you (re)start the browser. I'm looking at you, YouTube...

* Some WiFi hotspots redirect all your website accesses to a login page, until you have logged in. In such circumstances, starting a browser with X number of tabs to restore will yield of you X copies of the login page -- not fun. With BarTab you'll only get one.
Also this would help with the multiple master password windows that pop up for all the tabs that need login credentials when you restart.
Blocks: cuts-startup
No longer blocks: papercuts
Other bugs about session restore performance and behavior with a large number of tabs: bug 394492, bug 402768, bug 507868, bug 521964.
Summary: Startup issue: Delay loading of background tabs (BarTab-like behavior) → Startup issue: Delay loading of background tabs (BarTab-like behavior) when restoring session
Load Tabs Progressively is a fantastic addon that sets a maximum number of tabs that can be loading simultaneously:
https://addons.mozilla.org/addon/91919/

On session restore, we could load the selected tab and its neighbors immediately and progressively load the rest.
Oh wow, I just failed to read the Load Tabs Progressively section in comment 2. Mea culpa.
Feels like there's some UI work to be done here:

 - what's the default behaviour?
 - is there new UI we'd present to users?
 - have we evaluated the tradeoffs between loading and not loading tabs?

We should also compare to competitors' solutions in terms of discoverability, ease of use, and performance.

What I think is clear is that we should delay the loading until after the first tab comes back. From there our options are many. I'm pretty sure that BarTab's solution isn't right, as it trades off maximal instant convenience (one tab only) for minimal future convenience (it's a PITA when you eventually select another tab and then have to wait).
- concerning trade off between loading and not loading:

NOT loading is ALWAYS much faster, the titles of the tabs are retrieved from history, and instantly it looks like the browser is back where you started.

a lot of users open many tabs, then take another day time to go through the tabs. the default can be set how long of inactivety a tab will be unloaded. eg after 40 mins no viewing, means the 10-20MB and the CPU cycles a page is using, probably will not be used in the near future, and just loading the page again takes 1-2second. having 30 loaded tabs around while you are only viewing the latest 20 is just having 300-600MB waisted. and not everyone has 4GB mem. most users have 500MB-1GB. at no time is it needed to have to switch fast between 50+pages instantaniously, only the last maybe 20. 

on restore, you are not istantly going to read 50 pages, or 20, no you start with the one you wanted. since the titles and icons are all there selecting the one you want is fast, (seeing the icons) and opening it is GUARANTEED faster since you are only opening the one you want to view and not 10 at the same time. 

when the browser opens 50 pages, (=500-1200MB memory usage) switching between them on most computers takes MORE time then when they are simply loaded again!

having used this extention a long time, and reading ALL the user reviews all 5 stars are given, (0 bad reviews! unlike many other extentions!) and i agree. there is just no reason NOT to use it.

obviously you first have to try it. because the performance difference can not be imagined, only experienced. 

difference WILL be noticed on a 1GB ram computer:
* noticable (3-5x faster!) at 20+tabs, opening and restoring
* noticable (2x faster) switching tabs at 50+tabs when browsing over a long time. (so tabs that are not used for over x mins are unloaded).
NOTE: switching to a tab that has not been used for 30 mins in a situation FF takes more memory then the computer has RAM practically guarantees it need to be restored from the swapfile. in my experience it is just faster loading the page again. using this approach means that the computer s not on the verge of memory exhaustion all the time (300Mb usage instead of over 1GB) while the browser is open (and you want it open all the time). Needless to say not only browsing is faster when there is available RAM, also everything else.

I know developers are nerds that have the latest equipment, but i also know you love your old finetuned oldies. i do. and they work fine. with bartab.

granted the name is not proffesional (but i propose a toast anyway!), who needs to know? just build the feature in ff, and i am SURE it will get more popular.
> I'm pretty sure that BarTab's solution isn't right, as it trades off maximal
> instant convenience (one tab only) for minimal future convenience (it's a
> PITA when you eventually select another tab and then have to wait).

While I personally like BarTab's solution, I'd agree that it doesn't sound like the right thing to do by default.

> what's the default behaviour?

To ask upon closing of Firefox whether to save the tabs, like it does currently. If the user activates "Show tabs from last session" then this feature kicks in without any further settings or questions. 

So, when the browser starts all tabs and windows are shown, but initially only the last active tab gets loaded. Once the active tab has finished loading *and the user is not actively interacting with the browser* start loading other tabs, but don't load too many in parallel because in low RAM situations this *will* impact UI responsiveness. 1 tab at a time sounds best to me, possibly tweakable via about:config.

What the not-yet-loaded tabs should look like: the same as the already-loaded tabs. I would also advocate for the favicon *not* to be animated during the background loading, so as to avoid distracting the user from what they are doing. Basically it should look like all tabs became resurrected instantly, and the background loading of inactive tabs should be invisible.

If the user switches to a tab that's not yet loaded: it starts to load immediately. Any other tabs that have already started loading in the background may finish, but no new background loads should begin until the current tab is done. The favicon should be animated as usual. The tab would start off blank like tabs always do, and render normally.

If the user switches to a tab that has started background-loading but hasn't finished yet: the favicon becomes animated. Otherwise it's just like switching to a not-yet-fully-loaded tab in the current builds.

> is there new UI we'd present to users?

In the minimal case described above, no.

An additional benefit of permanently suspending the loading of tabs until the user activates one is that websites that start making noises or consuming CPU remain inactive indefinitely. This might be the preferred behaviour for some users (like me) - helps resuming a session that has 20 YouTube tabs in it. This could be implemented by adding an extra item to the Options / General / "When Firefox Starts", called something along the lines of "Show tabs from the previous session but don't load them until I use them". In this case the unloaded tabs should be grayed out.


> have we evaluated the tradeoffs between loading and not loading tabs?

In the minimal case:

- first tab becomes usable much sooner
- browser as a whole becomes usable much sooner (e.g. create and use a new tab) especially on low-end systems
- some of the tabs may end up being available later than they would do in current builds (but the idea is that the _average_ time until a random tab becomes available is reduced)
(In reply to comment #8)
> What I think is clear is that we should delay the loading until after the first
> tab comes back. From there our options are many. I'm pretty sure that BarTab's
> solution isn't right, as it trades off maximal instant convenience (one tab
> only) for minimal future convenience (it's a PITA when you eventually select
> another tab and then have to wait).

Agreed. The goal is to make the browser more responsive right after session restore while not inconveniencing users who explicitly want their sessions restored. BarTab itself is a hack that may continue to work for some users, but certainly not all. Instead of preventing tabs from loading we should just load them progressively after the first tab has been restored. If the user switches tabs in between, the newly selected tab gets priority, of course.

>  - what's the default behaviour?
>  - is there new UI we'd present to users?

These are good questions. The current behaviour with asking on exit clearly is disturbing. People tend to just answer "no" to any question they're asked when exiting an application.

We should ask on start-up instead. We already do after two consecutive crashes, though it was suggested by Alex Faaborg to provide this option on the new Home tab, e.g. a button "Restore my X windows with Y tabs". Of course there would also be an option to have Firefox do this automatically on all starts, like there is now. In both cases we should restore tabs progressively, prioritised by selectedness and visibility.
My suggestion for the loading of multiple tabs (at start-up and when loading bookmark groups):

Step 1. Load the active tab.
Step 2. Branch based on pref: "Load background tabs immediately"
     2a. [Unchecked] - Behaviour of "BarTab" extension (i.e. load on click)
     2b. [Checked] - Behaviour of "Load Tabs Progressively" extension.
                     pref: "Load X background tabs at a time"
                     0 = all tabs at once (?).
                     Tabs should be loaded in MRU order (see bug 496458)
                     pref: "Load most-recent X tabs" (or based on time: tabs opened this week, tabs opened in the last 30 days, etc. [I prefer the numeric option, unless both options are supported]). Other tabs would load on click.

*** What's the default behaviour? ***

Load background tabs immediately = true
Load X background tabs at a time = 3 (debatable)
Load most-recent X tabs = 0 (all tabs)

I agree with Roman that the favicon of background tabs should not be animated (indeterminate progress indicator), and that new activity should pause the loading of background tabs.

*** Is there new UI we'd present to users? ***

Nope, just preferences:

Options -> Tabs

[x] Load background tabs immediately?
        Load [3] background tabs at a time.
        Load the most-recent [0] tabs. (0 = all tabs)

*** Have we evaluated the tradeoffs between loading and not loading tabs? ***

I think different users have vastly different requirements, and the preferences above will cater for almost all users. With the defaults above, the changes would hardly be noticeable to light users, and would improve perceived performance for heavier users.
(In reply to comment #12)
> Nope, just preferences

You really think this is worth adding a section to the preferences? We should just find out what "works" (as in, works better than the current behavior) for most users and let people who really want to tweak do so in about:config.
For people on slow and/or capped connections, BarTab has been a *huge* improvement.  For them, the benefit comes not just from saving CPU cycles or prioritizing network use, but from the ability to keep from loading tabs *at all* until you want them.

Before BarTab, there was a bandwidth cost associated with keeping each tab open, and you paid it each time you restarted the browser. (Moderated by caching, but non-zero.) The cost was, obviously, two-fold: time spent waiting for the pages you want right now, and bandwidth spent loading pages you don't need right away.

Before BarTab, I had to take an active role in managing my tabs and deciding whether it was worth it to keep each one open.  Now, I'm free to open a page as soon as it looks relevant, then get to it when I get to it.  This is because of the way BarTab won't reload a page until you ask for it by clicking that tab.

Because of BarTab, my usage mode has changed from having maybe 5-10 tabs at a time, to having 40-60 tabs and maybe a couple separate browser windows.  It's nice because you don't just have tabs for your current task, but also for the other tasks you're not actively working.  

I may restart the browser 100 times (twenty times a day, five days) before I look at the contents of a given tab.  I don't want to pay the bandwidth cost until I'm ready to actually look at it.  With BarTab's defer-until-clicked, it's no problem at all.

NoScript, Adblock Plus, BarTab - all add-ons that change your online life.

So, clearly I'm advocating for a way to configure Firefox's tab loading to "defer until clicked".

If there's no associated UI other than about:config, that just increases the value of a future blog post "Firefox Secrets for the Bandwidth-Constrained".
This will be even more necessary with Firefox Panorama, which essentially makes it easier for the user to leave more tabs open.
Now that bug 586068 has been fixed, all this requires (the non-trivial part anyway) is setting browser.sessionstore.max_concurrent_tabs to 0.
Depends on: 586068
Depends on: 597681
Blocks: 597681
No longer depends on: 597681
(In reply to comment #16)
> This will be even more necessary with Firefox Panorama, which essentially makes
> it easier for the user to leave more tabs open.

The panorama specific case is covered by bug 595601
(In reply to comment #13)
> You really think this is worth adding a section to the preferences? We should
> just find out what "works" (as in, works better than the current behavior) for
> most users and let people who really want to tweak do so in about:config.

If you think the preferences are too complicated for regular users, about:config is fine.
(In reply to comment #20)
> (In reply to comment #13)
> > You really think this is worth adding a section to the preferences? We should
> > just find out what "works" (as in, works better than the current behavior) for
> > most users and let people who really want to tweak do so in about:config.
>
> If you think the preferences are too complicated for regular users,
> about:config is fine.

Just wanted to chime in here on this -- I think adding something to preferences would be a good idea. Need not be a section, maybe just a checkbox in 'Advanced'. Like ...

[ ] Load tab only when visited

...or some such.

In any case, i'd like to emphasize the usability benefits (besides the performance ones discussed in other comments) as mentioned in comment #2 (ie: login pages -- forget the wifi hotspot use case, lets say I have tabs with bugzilla pages open, in the absence of delayed loading, after a restart I'd have to reload every open page post-login so that bugzilla sees the new session).

cheers,
- steve
It could be nice to to modify the confirm "savesession dialog" for people that will switch off Firefox with unloaded tabs but whant to be able to consult them offline next time they open the brower. Like when you leave office and the pursue your work in the train ;-)

See Bug 598285
Can we call this "fixed" now since bug 586068 is landed.
I'd like to keep it open until there's UI to enable it, or (my preference) we ship it that way by default.
(In reply to comment #24)
> I'd like to keep it open until there's UI to enable it, or (my preference) we
> ship it that way by default.

It is enabled by default isn't it? Or do you mean UI to control the number of tabs to restore concurrently?
BarTab-like means browser.sessionstore.max_concurrent_tabs = 0.
Blocks: 632012
Yes, bug 586068 fixed this (in that it makes the browser more responsive by doing cascading loads).

I'm going to push for lazy loading (and in which cases we should do it) in other bugs, but the main problem described in this bug is fixed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows NT 6.1; rv:6.0a1) Gecko/20110428 Firefox/6.0a1

After restoring a session with more than 150 tabs, the browser still feels unresponsive to a certain degree.
Hello,

In reply to Philipp von Weitershausen [:philikon] from bug 561149, comment 2

> > Does BarTab use other tricks ?
> 
> Yes. It actually prevents tabs that aren't needed from being loaded. When
> the nsISessionStore service restores tabs, BarTab will let it restore the
> browser object and the attached history, but not load the page itself. You
> can configure it to do the same when you open a link in a new background
> tab. The loading will eventually take place when you visit the tab (though
> other mechanisms would surely work). The initial idea was to reduce the
> number of CPU cycles for browser (re)starts, but it turned out it also helps
> with memory (ok, not too surprising I guess).
> 
> Some BarTab users have also reported other interesting usability side
> effects:
> 
> * A video or audio site won't start playing annoying sounds through your
> speakers when you (re)start the browser. I'm looking at you, YouTube...
> 
> * Some WiFi hotspots redirect all your website accesses to a login page,
> until you have logged in. In such circumstances, starting a browser with X
> number of tabs to restore will yield of you X copies of the login page --
> not fun. With BarTab you'll only get one.

That is interesting.

See request bug 680605.
Depends on: 745475
Depends on: 995736
You need to log in before you can comment on or make changes to this bug.