[UX] Improve the wording of the "Firefox is already running but not responding" error message.

NEW
Unassigned

Status

()

Toolkit
Startup and Profile System
3 years ago
2 years ago

People

(Reporter: verdi, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
All
Windows 7
Points:
2
Bug Flags:
firefox-backlog +
qe-verify -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ux])

(Reporter)

Description

3 years ago
Gavin in Bug 286355 comment 43 says:

"Re-purposing this title string for the button is not ideal from an l10n point of view (using the same string in different context is generally bad, even if they are the same in English). More importantly, in this case the resulting UX is also far from ideal - you need to hit "Close Firefox" to "continue starting" Firefox, from the user's point of view."
(Reporter)

Comment 1

3 years ago
Here's a suggestion:

Firefox is already running, but is not responding. Restart Firefox to open a new window.
[Cancel] [Restart Firefox]
(Reporter)

Updated

3 years ago
OS: Mac OS X → All
Hardware: x86 → All
Flags: firefox-backlog+
(In reply to Verdi [:verdi] from comment #1)
> Here's a suggestion:
> 
> Firefox is already running, but is not responding. Restart Firefox to open a
> new window.
> [Cancel] [Restart Firefox]

I think that if you use "Cancel" for the button label, the button should be right most. Left most cancel button is odd on Windows.

Anyway, "Cancel" sounds unclear what the button will do. Maybe, the meaning is "Cancel to launch new Firefox", but it's too long for the button label...

Updated

3 years ago
Flags: qe-verify-
Whiteboard: [ux]

Comment 3

3 years ago
I think the wording should reflect the fact that you're not just "restarting" Firefox, you're actively killing it and this is an unusual situation. I don't know if there's a good way to reflect in the UI/wording that clicking "Restart Firefox" may result in data corruption or other issues.

Comment 4

3 years ago
For now, this is windows-only.
OS: All → Windows 7

Comment 5

3 years ago
What does happen if you hit cancel?

If I'm reading this right, it sounds like the only option available to the user is to kill the current session and restart. If that's the case, I would suggest something like this:

"Firefox is already open, but is not responding. You must restart to continue."

Comment 6

3 years ago
Cancel would close the dialog and do nothing else. Some possible reasons you might want to hit cancel:

* you are a developer using -no-remote and you actually have the browser open and doing useful things
* your Firefox is busy/not responding, but you think it might recover and there is important unsaved data in it that you don't want to kill

Comment 7

3 years ago
Or perhaps in some cases if you launch Firefox twice very quickly (perhaps by multiple clicks on a shortcut), one Firefox will launch and the other will show this dialog. We only know of that happening on Linux, but that doesn't mean it couldn't happen on other platforms if something strange happened.

Comment 8

3 years ago
Thanks for the clarification.

How about this?

"Firefox is already open, but is not responding. Do you want to restart to continue? You may lose any unsaved information."

Comment 9

3 years ago
If firefox is already open than maybe if press cancel it should bring to foreground the correct profile if its already open. Or maybe dont alert and just bring to foreground. I use -no-remote a lot. Finding the right profile is a task.
(In reply to noitidart from comment #9)
> If firefox is already open than maybe if press cancel it should bring to
> foreground the correct profile if its already open. Or maybe dont alert and
> just bring to foreground. I use -no-remote a lot. Finding the right profile
> is a task.

Unfortunately this dialog is only displayed once the previous Firefox instance has shut down to the point where that is no longer possible.
(In reply to Matej Novak [:matej] from comment #8)
> Thanks for the clarification.
> 
> How about this?
> 
> "Firefox is already open, but is not responding. Do you want to restart to
> continue? You may lose any unsaved information."

I read "restart" here as restarting the computer, which will scare away a lot of people. Could we go with:

"Firefox has stalled and may need a jump start. Would you like to wait to see if it recovers or force Firefox to restart?

[Force restart] [Wait]"

Updated

3 years ago
Blocks: 1060424
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #11)
> (In reply to Matej Novak [:matej] from comment #8)
> > Thanks for the clarification.
> > 
> > How about this?
> > 
> > "Firefox is already open, but is not responding. Do you want to restart to
> > continue? You may lose any unsaved information."
> 
> I read "restart" here as restarting the computer, which will scare away a
> lot of people. Could we go with:
> 
> "Firefox has stalled and may need a jump start. Would you like to wait to
> see if it recovers or force Firefox to restart?
> 
> [Force restart] [Wait]"

I would simplify it a bit and change the order so it matches the buttons:

"Firefox has stalled. Would you like to restart Firefox or wait to see if it recovers?

[Restart] [Wait]"

Comment 13

3 years ago
What would "wait" do? Close the dialog completely or something else?

Updated

3 years ago
Flags: needinfo?(Mnovak)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #13)
> What would "wait" do? Close the dialog completely or something else?

I don't think I'm the right person to answer that question.
Flags: needinfo?(Mnovak)

Comment 15

3 years ago
I don't understand what kind of feedback you're trying to provide, then. Are you trying to design the dialog UX, or just provide new strings for the existing dialog? ISTM that "Wait" is clearly incorrect labeling for the current button behavior, which is to just close the dialog and quit.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #15)
> I don't understand what kind of feedback you're trying to provide, then. Are
> you trying to design the dialog UX, or just provide new strings for the
> existing dialog? ISTM that "Wait" is clearly incorrect labeling for the
> current button behavior, which is to just close the dialog and quit.

I'm just here for copy. The first time I saw "Wait" as an option was when Jared suggested it in comment 11. I was just editing his proposed copy.

Please let me know when you've sorted out the buttons and behavior and I'll jump back in.
bsmedberg and I talked over IRC and came to:

Firefox has stalled. Would you like to restart Firefox or wait to see if it recovers?
[Force restart] [Cancel]

This is similar to Windows shutdown that offers a "Force restart" / "Cancel" if there are programs that are being slow to shut down and are blocking Windows' shutdown.

Matej, does this look OK to you?
Flags: needinfo?(Mnovak)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #17)
> bsmedberg and I talked over IRC and came to:
> 
> Firefox has stalled. Would you like to restart Firefox or wait to see if it
> recovers?
> [Force restart] [Cancel]
> 
> This is similar to Windows shutdown that offers a "Force restart" / "Cancel"
> if there are programs that are being slow to shut down and are blocking
> Windows' shutdown.
> 
> Matej, does this look OK to you?

"Force" seems a little scary to me on the button and it doesn't seem to add much, so I'd still prefer to remove that, but if you think it's essential, I can live with it.

My bigger concern is that we're giving users a choice in the string that's different from the one represented on the buttons. If I saw that for the first time, I don't think it would be clear to me if "Cancel" means that I want to wait, or if that's actually a third option.

I guess I don't fully understand why "Wait" doesn't work for the button, but then that's not my area of expertise.
Flags: needinfo?(Mnovak)
(In reply to Matej Novak [:matej] from comment #18)
> I guess I don't fully understand why "Wait" doesn't work for the button, but
> then that's not my area of expertise.

It is true that the user might want to wait for the other process to (hopefully) finish shutting down. However, there is no such thing as a "Wait" command, which is what such a button implies. Clicking the "Wait" button would just cause the current Firefox process to quit, which is probably not what the user would be expecting.

Updated

3 years ago
Points: --- → 2
(In reply to Aaron Klotz [:aklotz] from comment #19)
> (In reply to Matej Novak [:matej] from comment #18)
> > I guess I don't fully understand why "Wait" doesn't work for the button, but
> > then that's not my area of expertise.
> 
> It is true that the user might want to wait for the other process to
> (hopefully) finish shutting down. However, there is no such thing as a
> "Wait" command, which is what such a button implies. Clicking the "Wait"
> button would just cause the current Firefox process to quit, which is
> probably not what the user would be expecting.

Thanks for the clarification.

Based on that, it sounds like we should also remove the "wait" option from the string (if the only thing the user can do is restart).
It seems like we're running into some difficulty here because this dialog comes up in a couple of different situations, so we're trying to make one conversation that will suffice for users with different contexts in their heads.

It sounds like this comes up for:
- users who are trying to start Firefox, not realizing/caring that it's still running in the background, and just want to get on with starting it
- users who have it running in the background on purpose when they try to start it again and may want to wait for something to finish? (not sure here)
- users who see it when they're not in the midst of trying to start Firefox and then have to make or defer a choice to quit or restart

(this set is based on what I've seen in the bug so far -- some of these may not be real and/or there may be others)

The original intent for this bug was to make a more comprehensible experience for people in the first case in that list, but you can see that a dialog like

     Firefox has stalled. Would you like to restart Firefox or wait to see if it recovers?
     [Force restart] [Cancel]

doesn't really help there while it does speak directly to people in the second case. (It's also not clear to me that "Cancel" communicates what will happen next here, but that's the smaller issue).

My _guess_ is that the first case above is the most common, and so it's probably worth having a dialog that makes more sense for that one but possibly less for the others. Or would/could we have different versions of this without blowing the scope of this out too much?

Comment 22

3 years ago
> It sounds like this comes up for:
> - users who are trying to start Firefox, not realizing/caring that it's
> still running in the background, and just want to get on with starting it

This would almost exclusively be developers or technical users who are using -no-remote.

> - users who have it running in the background on purpose when they try to
> start it again and may want to wait for something to finish? (not sure here)

This is probably the majority case, although "on purpose" is probably not accurate. The most common situation here is that a user thought they closed Firefox, but actually it got stuck during shutdown and didn't actually finish closing.

> - users who see it when they're not in the midst of trying to start Firefox
> and then have to make or defer a choice to quit or restart

This dialog only shows up when Firefox is starting. The user may not be aware of this case: maybe they clicked a link in some other app which is launching Firefox because it's the default browser.

> possibly less for the others. Or would/could we have different versions of
> this without blowing the scope of this out too much?

There are a few clear signals here: if the browser was launched with -no-remote then we're likely hitting the first case and could easily customize the dialog to that case.

Otherwise, we probably can't easily distinguish why the profile is locked, only that there is another Firefox still using it.
You need to log in before you can comment on or make changes to this bug.