Open Bug 684548 Opened 13 years ago Updated 2 years ago

Allow restoring tabs/windows one by one to solve various issues (crash, overload, portal login ...)

Categories

(Firefox :: Session Restore, enhancement)

enhancement

Tracking

()

People

(Reporter: A.Pirard.Papou, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110805 Ubuntu/10.04 (lucid) Firefox/3.6.20
Build ID: 20110805211839

Steps to reproduce:

Nothing, *it* (Firefox) did freeze, or got caught in a portal trap or etc... :-)


Actual results:

I spent a long time guessing which page was preventing restart, while doing that I had to remove innocent pages I would have preferred to keep, logging to a "captive portal" lost all my open pages, etc etc...


Expected results:

Restoring sessions when Firefox restarts is an amazing feature.   But if an undetermined page freezes Firefox repeatedly, it may need many restarts and killing innocent pages to spot the culprit by guessing.
On the  "Well this is embarrassing" error screen, Firefox might allow to selectively restart each window or tab one by one (and you wait until they settled).  It would then be straightforward to determine which window/tab freezes Firefox and is to be skipped after just two or three restarts.

That is, 4 restart options on "Well this is embarrassing":
1: selectively start one window or tab immediately (one by one), they may be removed from the list for clarity,
2: selectively remove windows or tabs that will never restart, idem,
3: start all remaining pages,
4: remove all remaining pages.

Always restarting Firefox with that scheme on that "Well this is no longer embarrassing" page may help:
- those who complain that too many pages restart and who will be able to select which ones do
- those who login to a "captive portal" and who suddenly find all their restarting pages intercepted and replaced with the portal's login: my system puts all pages on hold and the user opens a fresh page to login, after which he unleashes all the other pages, en masse or not,
- those who don't understand the options (crash or no crash, etc) and want a predictable restart behavior,
- probably other situations...
OS: Linux → All
Hardware: x86 → All
Capability to selectively restart tabs is already in aurora builds which will become Firefox 8, an option appears in preferences which means it can be chosen before a crash happens.

Instead of duping this bug to that one, perhaps narrowing the scope of this bug to also have the browser.sessionstore.restore_on_demand preference exposed within the about:sessionrestore page is better.
OS: All → Linux
Hardware: All → x86
Summary: Better session restore after Firefox restart froze and other situations → expose the browser.sessionstore.restore_on_demand preference in about:sessionrestore
OS: Linux → All
Hardware: x86 → All
OK, but the title has become gibberish ;-)
Can you please give a pointer to that other bug? Thank you.
Zarro Boogs using your phrases.
Severity: normal → enhancement
Sorry, bug 648683 is what I meant to mention in my last comment.
Depends on: 648683
Sorry it doesn't work for me.
Searched for Aurora, found a nightly build (2) on some ppa (1), downloaded/installed it daily (2) on some maverick.
The sessions that were previously open in Firefox were lost.
If I quit Aurora, it does not ask for saving sessions, less does it restore them.
I checked all the settings OK on
http://support.mozilla.com/en-US/kb/Session%20Restore#w_when-you-tell-firefox-to-save-your-tabs-on-exit
There is no "Show my windows and tabs from last time".

(1) there would probably more beta testers if http://www.mozilla.org/en-US/firefox/channel/ showed the ppa
(2) my day is at GMT+1 but I don't know where their night is; hope it's OK ;-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Please read what I suggested.
I succeeded getting Aurora restore sessions.
I set set "restore tabs on-demand" as per bug 648683.
But neither bug 648683 nor about:sessionrestore does what I suggested.
Therefore, I restored this bug's title as initially.

Let's recall that the goals of my suggestion are:
- identifying which particular Web page crashes sessions restart and being able to skip only that page
- pacing down the rush restoring too many pages at once (causes user complaints about problems)
- putting restarting sessions on hold until a Captive Portal login is made (see bug
- ...  (any reason for not seeing all pages rush into restore at once)

Hence, about:sessionrestore must
- optionally start on every restart
- allow
  - to start each window or tab one by one with a click of its entry,
  - to eliminate them from the restore list as soon as restart is clicked
  - the user to wait until they are fully restored before clicking more restarts

This is not what about:sessionrestore presents.
Presently, one loses the eliminated pages forever and one must restart the rest at the same time.
Summary: expose the browser.sessionstore.restore_on_demand preference in about:sessionrestore → Allow restoring tabs/windows one by one to solve various issues (crash, overload, portal login ...)
See 
Bug 555551 about Portal Login issue
Bug 507868 about restore rush issue
Bug 677003 about a failing restore issue
Bug 501995 idem
and maybe more liable to be solved by this suggestion.
(In reply to André Pirard from comment #5)
> Let's recall that the goals of my suggestion are:
> - identifying which particular Web page crashes sessions restart and being
> able to skip only that page

You can double click on single entries from the list to restore that tab. It doesn't remove from the list, but I think that's ok.

> - pacing down the rush restoring too many pages at once (causes user
> complaints about problems)

We currently have limited session restore to only load 3 tabs at a time, and further limited that to 0 when you have restore on demand selected.

> - putting restarting sessions on hold until a Captive Portal login is made

That's covered by other bugs as you've mentioned.

about:sessionrestore is not meant to be a very feature-rich page. It's a last line of defense and as we eliminate causes for crashes, it becomes less & less important. You have some ideas which I'd be ok with taking, namely opening a whole window from about:sessionrestore. I have no intention of working on that right now but if there is a solution with code presented, I would look at it.
Thanks for your interest in this.
Best saying which version: my testing 7.0.1 on Ubuntu 11.10 on Virtualbox

> You can double click on single entries from the list to restore that tab. It
> doesn't remove from the list, but I think that's ok.
That's so great it would be worth mentioning it in Restore page so that the user knows.
Suggestion: "You can try... - double-clicking tabs to be restored one by one and see which fails"

A KEY point for Portal issues and other unforeseen ones (or seen ones like Session Restore not starting when it should) is being able to ALWAYS restart with Session Restore (safety at 1 more click cost).
I suggest: Edit/Preferences/General/Startup/When Firefox Starts:
Always show the Session Restore page.

It seems normal and would be "friendly" to remove the tick after the tab is restored instead of having to do it manually.

Would a whole window restore be feasible as a speed up?  (Imagine 20 pages of 10 tabs each)

>> - putting restarting sessions on hold until a Captive Portal login is made
> That's covered by other bugs as you've mentioned.
Bug 555551 : my conclusion is:
- that Paul's project to modify all portals and all browsers is a vast undertaking
- that WPA should be used and that portal problems are not browser problems (but they can participate in a handshaking protocol and *that* is another issue)
- but that, in the meantime, Firefox doing its best to cope with the problems that way would make it the best

>> - pacing down the rush restoring too many pages at once (causes user
>> complaints about problems)
>
> We currently have limited session restore to only load 3 tabs at a time, and
> further limited that to 0 when you have restore on demand selected.
Nice, but...
Ouch, that gets in the way of the portal algorithm I suggest in Bug 555551.
When is another 3 tabs restore started (delay, activity, ?)?
Or, better yet, where can we read those details if possible?

> about:sessionrestore is not meant to be a very feature-rich page. ...
There's a Session Manager add-on discovered lately and to be examined yet.
But the inconvenience of such an add-on is that it is not installed when you need it.
Especially, little chance to have it installed at a hotel or airport reception desk.
The minimal features must be Firefox resident and minimal is just OK to me.
Related bug: https://bugzilla.mozilla.org/show_bug.cgi?id=555551
"Session restore functionality is broken by captive portal software"
Depends on: 590448
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.