Open Bug 704000 Opened 13 years ago Updated 2 years ago

Restore max_concurrent_tabs preference OR change default hard-coded value of "3"

Categories

(Firefox :: Session Restore, enhancement)

11 Branch
x86
Windows XP
enhancement

Tracking

()

People

(Reporter: bugzilla.mxm, Unassigned)

References

Details

Starting with Firefox 8, the preference browser.sessionstore.max_concurrent_tabs was removed (see Bug 648683) and was replaced with a "switch" (browser.sessionstore.restore_on_demand) that is accessible from the Preferences window and only accepts 2 values: true (tabs are loaded only when selected) or false (all tabs are loaded, 3 at a time) The value "3 at a time" is now hard-coded and cannot be customized as was previously possible with the preference max_concurrent_tabs. My question is: why hard-coded? why 3? Was there any performance analysis showing that loading 3 tabs at a time finished loading all tabs quicker than loading, say, 5 tabs at a time or 10 tabs at a time? I'm a heavy tabs user (> 50 tabs) and I had my max_concurrent_tabs preference customized to 8 tabs at a time. When I updated to firefox 8, that value was obviously reset to 3 tabs at a time. I can now see a noticeable delay in the total time it takes to load all my tabs after a restart. Would it be possible to bring back the preference max_concurrent_tabs? Or, at least, to change the hard-coded value of "3 tabs at a time" to some higher value? (5? 6? 8 tabs at a time?) I think many heavy users like me would appreciate such a change. And, after all, this preference is precisely geared towards heavy users. People who only open a couple of tabs certainly don't need these preferences.
Depends on: 648683
Component: Preferences → Session Restore
QA Contact: preferences → session.restore
This bug is still present in Firefox 11. The bug it depends on (Bug 648683) has now been RESOLVED and VERIFIED. Given that (I think) this bug complies with the requirements mentioned on https://developer.mozilla.org/en/Confirming_unconfirmed_bugs, could someone with the "canconfirm" privilege effectively confirm it and change its status to NEW? Thanks
Version: 8 Branch → 11 Branch
Will confirm as an enhancement request
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
is anybody interested in fixing it?
Actually, if you look at the code, you will see that the "3 at a time" value is not even applied correctly. I'm not sure reintroducing the preference would help much.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.