Closed Bug 589272 Opened 14 years ago Closed 13 years ago

Improve language of "Start New Session" string in about:sessionrestore

Categories

(Firefox :: Session Restore, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 523140

People

(Reporter: u279076, Unassigned)

References

Details

With the removal of the "Start New Session" button from about:sessionrestore (bug 477322), the bullet point describing that activity does a poor job of communicating this functionality:

---
You can try:
* Removing one or more tabs that you think may be causing the problem
* Starting an entirely new browsing session
---

This string does a poor job of both how one starts a new session and the implications of that action.

I propose changing the string to address both.  Something like:
"Start a new session by clicking the HOME button or simply browsing to any website.  Notice, doing so will remove anything done in the previous session."
Adding blocking2.0? as advised by zpao on IRC.
blocking2.0: --- → ?
Beltzner, since you had some issues with this in bug 477322, do you have thoughts on what we might want to do here?
Blocks: 477322
Yeah, I'll take a pass in a moment.
blocking2.0: ? → beta5+
A reference to closing the current tab would probably be the most universal case (in the event they customized their ui)
When one restores from repeated crashes, the only tab shown is about:sessionrestore. When there's only one tab shown, you can't close it.

We can't tell users to close the tab, since they can't do that.

(Yes, if we get the "home button as app tab" fix this goes away, but so far I haven't seen a patch or even a bug on that, so I don't think we can count on it at this time)
This idea might be a bit radical, but I'll throw it out there:

What if we always default to the home page on start up.  If there is a session to restore display a doorhanger telling the user "It appears there is a previously saved session.  Would you like to restore it? Yes | No | More".

Yes - restore the session as it was saved
No - doorhanger closes, user continues to browse
More - load about:sessionrestore so user can select what to restore

This would also give the person to ignore the doorhanger altogether and just keep browsing.

I'm not a UX expert, so the language probably needs tweaking, but what about the core idea?
(In reply to comment #6)
> This idea might be a bit radical, but I'll throw it out there:
> 
> What if we always default to the home page on start up.  If there is a session
> to restore display a doorhanger telling the user "It appears there is a
> previously saved session.  Would you like to restore it? Yes | No | More".
> 
> Yes - restore the session as it was saved
> No - doorhanger closes, user continues to browse
> More - load about:sessionrestore so user can select what to restore
> 
> This would also give the person to ignore the doorhanger altogether and just
> keep browsing.
> 
> I'm not a UX expert, so the language probably needs tweaking, but what about
> the core idea?

It's not a totally radical idea. In fact, that's pretty much what bug 588482 is about (except not a doorhanger). The problem comes in that I think we still want to restore following a crash. Doing a doorhanger at this point is going to be too much. Ideally we wanted something on the home tab, but that's looking pretty unlikely right now.

It's possible though that we still open the home page(s) and then assuming no session state changes when they "restore session" we just close the home pages. That's a case that it looks like I'll need to handle in that other bug anyway (if you restore on demand with home pages open, what happens? probably what I just described)
Bug 477322 was backed out, so this no longer blocks beta 5.
blocking2.0: beta5+ → ---
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.