1845112 - Troubleshoot Mode confirmation can be confusing when triggered by key in another app

Status: NEW

(Toolkit :: Startup and Profile System, defect)

Description

[Erich Gubler [:ErichDonGubler] (he/him)]

Troubleshoot Mode can be used to debug Firefox issues in user configuration. When triggered, it interrupts a typical opening of Firefox, asking the user to confirm that Troubleshoot Mode is actually desired with a dialog titled Open Firefox in Troubleshoot Mode? (in English translations). Mozilla Support documents two ways to trigger Troubleshoot Mode when starting Firefox:

1. Use the Troubleshoot Mode… menu entry in the Help section of the app menu strip. This trigger is not relevant for this bug.
2. Hold a platform-specific modifier key while the process is starting. On Linux and Windows, this is Shift. On Mac, this is the Option key.

Trigger 2 is known to happen unintentionally, i.e., while Firefox restarts for an update and the user performs other tasks in which the user holds a Shift or Option key. This can result in an unintended interruption of Firefox start-up. Furthermore, if a user not well-versed in Troubleshoot Mode behavior, they may be confused at why it has been triggered in the first place.

Comment 1

[Erich Gubler [:ErichDonGubler] (he/him)]

Recommended solution: Include information about why the Troubleshoot Mode dialog was triggered when presented. Currently, the text of the dialog is (in English):

Use this special mode of Firefox to diagnose issues. Your extensions and customizations will be temporarily disabled.

You can also skip troubleshooting and refresh Firefox, instead.

I suggest introducing the current message with a summary of why Troubleshoot Mode was triggered; concretely, in the case of a keyboard trigger, one might present (my addition emphasized in bold):

We detected that the Option key was held down while Firefox started up, which we think means that you'd like Troubleshoot Mode. Use this special mode …

I will leave it to the judgment of code owners whether additional text seems necessary in the case that Troubleshoot Mode was explicitly triggered from the Help menu.

Comment 2

[Andreas Wagner [:TheOne] [use NI]]

This can result in an unintended interruption of Firefox start-up. Furthermore, if a user not well-versed in Troubleshoot Mode behavior, they may be confused at why it has been triggered in the first place.

And how to start in regular mode. The only available options are:

• Open [in Troubleshoot Mode]
• Refresh Firefox

An option to start in regular mode instead would also be helpful. The workaround is to manually close the dialog via the window control button and then manually start Firefox again.

Comment 4

[:Gijs (he/him)]

Meridel, this would be relatively straightforward for engineering to implement if we knew what text options we wanted here. Basically, this dialog can show up if...

1. the user requested to open troubleshoot mode from the "Help" menu, from about:support, or from about:profiles.
2. the user restarts the browser while in safe mode - could be to apply updates, or by using the 'restart' action elsewhere in the browser.
3. on Windows and macOS, if the user keeps the shift respectively option key pressed while starting Firefox
4. in response to crashes.

For (1) and (2) I suggest we wouldn't surface an option to use normal mode, nor add any supplementary text. The user has made this choice already and it shouldn't be a surprise (plus we cannot easily distinguish 1 from 2 - only from the other options).

For (3) I think we should have a bit of clarifying text in the dialog + a "start in normal mode" button (content text obviously tbd!) to give people an obvious "way out" of this dialog.

For (4), this would be nice but it's not currently easily distinguishable from (1) and (2) so I'd move that to a follow-up.

Meridel, do you think someone could come up with some text for (3) and for the "normal" restart button?

Comment 5

[Meridel [:meridel]]

Brian, can you please provide content design support here? Thank you.

Comment 6

[Brian Jones]

Since the [TITLE] key was pressed, Firefox started in Troubleshoot Mode. Extensions, themes and custom settings are disabled in Troubleshoot Mode.
<Buttons>
Continue in Troubleshoot Mode
Refresh Firefox
Restart in Normal Mode

Comment 7

[Francesco Lodolo [:flod]]

(In reply to Brian Jones from comment #6)

<Buttons>
Continue in Troubleshoot Mode
Refresh Firefox
Restart in Normal Mode

All these are very long labels in English, and will get out of control when localize. For reference, "Troubleshoot mode" across locales
https://transvision.flod.org/string/?entity=toolkit/toolkit/about/aboutSupport.ftl:restart-in-troubleshoot-mode-label&repo=gecko_strings

We should find a way to simplify these labels.

Comment 8

[Francesco Lodolo [:flod]]

@bryan
Could you take a look at my message above? Maybe we could move part of the content to the message, to make the labels shorter?

e.g.

Since the [TITLE] key was pressed, Firefox started in Troubleshoot Mode. Extensions, themes and custom settings are disabled in Troubleshoot Mode. You can continue in Troubleshoot Mode, restart Firefox normally, or try refreshing Firefox.
<Buttons>
Continue
Refresh Firefox
Restart

Comment 9

[Brian Jones]

Concerned that those labels, absent the "mode" info, lack needed context, especially the "Continue" button.
Think we can get that needed context via:
Continue
Refresh
Restart in Normal Mode

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Translations' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 11

[:Gijs (he/him)]

The handling of opt/shift lives somewhere in startup code, IIRC, so moving over there. Definitely not translations...

Comment 12

[:Gijs (he/him)]

Going to cheat horribly and mark this a defect so it shows up in triage. This seems like a relatively straightforward quality of life win, and all the content design work got done already.

In fact, I looked at doing this but then got a bit stuck. @Mossop, is (3) in comment #4 just distinguishable because it's the only case in which we don't have the MOZ_SAFE_MODE_RESTART env var set?

Comment 13

[Dave Townsend [:mossop]]

(In reply to :Gijs (he/him) from comment #12)

Going to cheat horribly and mark this a defect so it shows up in triage. This seems like a relatively straightforward quality of life win, and all the content design work got done already.

In fact, I looked at doing this but then got a bit stuck. @Mossop, is (3) in comment #4 just distinguishable because it's the only case in which we don't have the MOZ_SAFE_MODE_RESTART env var set?

When we do the check for whether to start in safe mode we unset the environment variable so I don't think you can distinguish on that. You might want to amend IsSafeModeRequested to return an enum containing why safe mode was enabled and then change the type of gSafeMode to hold that and add a new attribute to nsIXULRuntime to return that.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit BugBot documentation.

Comment 15

[Dave Townsend [:mossop]]

(In reply to :Gijs (he/him) from comment #12)

Going to cheat horribly and mark this a defect so it shows up in triage. This seems like a relatively straightforward quality of life win, and all the content design work got done already.

Then can you give it a severity so I don't get pinged about it :p

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit BugBot documentation.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1845128: S3

:mossop, could you consider increasing the severity of this bug to S3?

For more information, please visit BugBot documentation.

Comment 18

[pokechu022]

This happens to me relatively often, mainly with Nightly or when using Mozregression. I often alt-tab into another app while Nightly is updating, and then happen to be holding shift when it finishes updating, causing the dialog to appear. I then have to click the close button and manually launch nightly a second time. I somehow already knew or guessed that shift activates troubleshoot mode, but the lack of a way to launch normally is really inconvenient.

Between the two I think it happens more often to me and is more irritating with Mozregression, but resolving it with Mozregression would be impossible because it can't be fixed retroactively in all old versions.

Comment 19

[:Gijs (he/him)]

(In reply to pokechu022 from comment #18)

This happens to me relatively often, mainly with Nightly or when using Mozregression.

You can already set the environment variable MOZ_DISABLE_SAFE_MODE_KEY to disable this. mozregression should probably set that in the environment "for you" when it runs executables. I filed bug 1974882. This env var has worked since 2015, cf. bug 1140183.

I often alt-tab into another app while Nightly is updating, and then happen to be holding shift when it finishes updating, causing the dialog to appear.

Same for the updater. Filed bug 1974884.