Closed
Bug 589272
Opened 15 years ago
Closed 14 years ago
Improve language of "Start New Session" string in about:sessionrestore
Categories
(Firefox :: Session Restore, defect)
Firefox
Session Restore
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: --- → ?
Comment 2•15 years ago
|
||
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
Comment 4•15 years ago
|
||
A reference to closing the current tab would probably be the most universal case (in the event they customized their ui)
Comment 5•15 years ago
|
||
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?
Comment 7•15 years ago
|
||
(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)
Comment 8•15 years ago
|
||
Bug 477322 was backed out, so this no longer blocks beta 5.
blocking2.0: beta5+ → ---
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•