Provide a way to disable safe mode

ASSIGNED
Assigned to
(NeedInfo from)

Status

()

Firefox
General
ASSIGNED
6 years ago
2 years ago

People

(Reporter: mkaply, Assigned: mkaply, NeedInfo)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
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.

Updated

6 years ago
Blocks: 599835

Comment 1

6 years ago
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).
(Assignee)

Comment 2

5 years ago
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

5 years ago
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

5 years ago
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.
(Assignee)

Comment 5

5 years ago
> 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

3 years ago
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?
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

3 years ago
+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

2 years ago
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.
Flags: needinfo?(mozilla)
(Assignee)

Comment 10

2 years ago
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/
Flags: needinfo?(mozilla)

Comment 11

2 years ago
I'm not sure how feasible that is. Some of these checks happen very early in startup.
(Assignee)

Comment 12

2 years ago
Then maybe something in override.ini
(Assignee)

Comment 13

2 years ago
Created attachment 8664863 [details] [diff] [review]
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.
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
(Assignee)

Comment 14

2 years ago
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?
(Assignee)

Comment 15

2 years ago
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.
Attachment #8664863 - Flags: review?(benjamin)
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.
Attachment #8664863 - Flags: review?(benjamin) → review-
(Assignee)

Comment 17

2 years ago
> 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.
Flags: needinfo?(kev)
You need to log in before you can comment on or make changes to this bug.