653410 - Provide a way to disable safe mode

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Mike Kaply [:mkaply]]

While safe mode is great for debugging problems, in a corporate environment where browsers are locked down and certain extensions installed, providing the user an easy way to bypass all the locking that was put in place is a problem.

There should be a way for an administrator to disable Firefox's ability to be placed into safe mode.

Comment 1

[Richard van den Berg]

Since FF 4 all users have to do is hold down the Shift key. Way too easy. In a Windows environment, one way of fixing this would be to check a registry key. If it exists: deny running in Safe Mode. This way, desktop support personnel can remove this key, and run Safe Mode to do troubleshooting. Afterward the registry key should be set again (Group Policy can take care of this).

Comment 2

[Mike Kaply [:mkaply]]

This has become a much bigger problem with the landing of bug 732303.

It is now not possible to disable the safe mode dialog via an overlay (see http://mike.kaply.com/2012/04/10/customizing-firefox-disabling-safe-mode/ )

There should really be a way for an admin to disable safe mode.

Even something as simple as a kiosk doesn't work well because of this.

Comment 3

[Jesse Ruderman]

Maybe it would be better to force certain extensions to remain enabled in safe mode, rather than disabling safe mode entirely.  Do any other aspects of safe mode create problems for your environment?

That said, I'd really like a way to disable the "feature" that holding Alt makes Firefox start in safe mode.  It's a royal pain for semi-automated testing.

Comment 4

[Richard van den Berg]

Jesse, did you read Mike's blog regarding putting extensions into the distribution/bundles directory? One of the benefits is they are also loaded during safe mode.

Comment 5

[Mike Kaply [:mkaply]]

> That said, I'd really like a way to disable the "feature" that holding Alt makes Firefox start in safe mode.  It's a royal pain for semi-automated testing.

Yeah, that's really the biggest deal here.

It impacts kiosks and any other place where someone is trying to lock down Firefox...

Comment 6

[Jukka Jylänki]

Any updates on this? This blocks my attempts to automate a unit test suite that runs tests in Firefox - if a rogue test fails, the test harness has no option but to kill the browser process, but in that case, all the subsequent tests fail as well since the Safe Mode dialog will pop up and nothing will actually load.

Is there an about:config pref that could be used to disable the Safe Mode from popping up? If not, can one be added?

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Set toolkit.startup.max_resumed_crashes to -1 to disable the automatic safe mode, see http://mxr.mozilla.org/mozilla-release/source/testing/mozbase/mozprofile/mozprofile/profile.py#409

Comment 8

[andrew.pennebaker]

+1 I really want to disable the Alt = Safe Mode hotkey.

@Archaeopteryx That doesn't help. My use case is I like setting global hotkeys for launching my favorite apps:

* Control+Alt+G Google Chrome
* Control+Alt+T Terminal
* Control+Alt+W Wunderlist

Using AutoHotkey, Quicksilver, or Ubuntu settings.

I'd love to add Firefox to this list, with Control+Alt+F, but Firefox *freaks out* when Alt is pressed.

Comment 9

[Jesse Ruderman]

There are now environment variables to disable two safe mode triggers. Do they suffice for calling this bug FIXED?

From bug 1140183, MOZ_DISABLE_SAFE_MODE_KEY disables the "hold alt" thing.
From bug 745154, MOZ_DISABLE_AUTO_SAFE_MODE makes crashes not trigger safe mode.

Comment 10

[Mike Kaply [:mkaply]]

Probably good enough. I still wish that there was a simple pref that could be flipped.

https://mike.kaply.com/2013/07/01/make-your-feature-enterprise-ready/

Comment 11

[Jesse Ruderman]

I'm not sure how feasible that is. Some of these checks happen very early in startup.

Comment 12

[Mike Kaply [:mkaply]]

Then maybe something in override.ini

Comment 13

[Mike Kaply [:mkaply]]

Attachment: Allow disabling safe mode in override.ini

Here's my idea.

If we end up in safe mode, then check if it has been disabled in override.ini.

This has no effect on startup unless safe mode is triggered.

Comment 14

[Mike Kaply [:mkaply]]

Note that profile migrator uses:

EnableProfileMigrator=0/1

Not sure if we should be consistent and be:

EnableSafeMode=0/1 (since enabled is the default).

Any idea on who would review this?

Comment 15

[Mike Kaply [:mkaply]]

Comment on attachment 8664863 [details] [diff] [review]
Allow disabling safe mode in override.ini

This code only takes effect when safe mode has enabled.

It does duplicate code from the wizard code but I wasn't sure it was worth creating a function for code that happens twice in non standard cases.

Comment 16

[Benjamin Smedberg]

Comment on attachment 8664863 [details] [diff] [review]
Allow disabling safe mode in override.ini

As for the product question of whether we want to allow people to disable safe mode or change how it behaves, I want Kev to help answer that question before I review the code.

In terms of the actual code, though, our override.ini behavior is fragmented and we should not add additional uses without fixing it. override.ini, if we decide to support it at all, should be read consistenly in one place and nsXREAppData should encode all the information. We cannot take the startup hit of reading override.ini synchronously in multiple phases of startup.

Comment 17

[Mike Kaply [:mkaply]]

> We cannot take the startup hit of reading override.ini synchronously in multiple phases of startup.

We would only take the startup hit if safe mode was actually invoked, so this would be a very rare case.

If you're proposing that we read override.ini at every startup, that seems like it would be the wrong path from a performance perspective. Right now we only read it if it is the very first profile.

Although honestly I wish we read override.ini at every startup. It would solve other problems (bug 723493).

I assume you meant kev needham for your commment. I've added a needinfo.

Comment 18

[Kev Needham [:kev]]

Oof. Bad kev. Old bug.

Given the environmental variable availability, I don't think this is something we'd want to provide in a simple-to-touch ini file. It makes management in deployed environments simpler, but also makes it super simple for any installer to make it difficult for a user to enter safe mode. I know any file installer can also set an environment variable, but I'd like to keep the number of methods to achieve the same thing down. For the enterprise use case, this falls into a more general class of GPO support from a central auth/config source.

Comment 19

[Jukka Jylänki]

(In reply to Jukka Jylänki from comment #6)
> Any updates on this? This blocks my attempts to automate a unit test suite
> that runs tests in Firefox - if a rogue test fails, the test harness has no
> option but to kill the browser process, but in that case, all the subsequent
> tests fail as well since the Safe Mode dialog will pop up and nothing will
> actually load.
> 
> Is there an about:config pref that could be used to disable the Safe Mode
> from popping up? If not, can one be added?

(In reply to Jesse Ruderman from comment #9)
> There are now environment variables to disable two safe mode triggers. Do
> they suffice for calling this bug FIXED?
> 
> From bug 1140183, MOZ_DISABLE_SAFE_MODE_KEY disables the "hold alt" thing.
> From bug 745154, MOZ_DISABLE_AUTO_SAFE_MODE makes crashes not trigger safe
> mode.

(In reply to Kev Needham [:kev] from comment #18)
> Oof. Bad kev. Old bug.
> 
> Given the environmental variable availability, I don't think this is
> something we'd want to provide in a simple-to-touch ini file.

The environment variables have worked well for emrun, which automates browser execution of .html pages. In emrun those are actively being used at https://github.com/juj/emrun/blob/master/emrun.py#L1143, so this sounds resolved at least from the perspective of comment 6.

Comment 20

[andrew.pennebaker]

Awesome, thanks for adding that environment variable! With a .plist tweak, macOS users can define this variable system-wide at boot, and successfully disable this annoying hotkey.

https://github.com/mcandre/dotfiles/blob/master/setenv.MOZ_DISABLE_SAFE_MODE_KEY.plist