934497 - Add option to disable developer tools

Status: RESOLVED WORKSFORME

(DevTools :: General, defect, P4)

Description

[Gangadhar Nittala(:gnittala)]

This is not a bug but a requirement

Use-Case:
1. User doesn't know anything about developer tools (average user who uses FF to browse the web and no more)
2. Accidentally hits F12
3. The window below the screen shows up the developer tools. User is not sure what happened, hits F12 again and the window is closed

Requirement
1. If there is an option to disable developer tools then only users who are aware of the option can enable it and the rest of the users are provided with a clutter free experience
2. The option could be 'Disable Devtools' by default
3. Provide a UI option to enable this in Preferences -> Advanced -> General as a checkbox
4. If not the above, provide a single about:config option that will disable devtools

Work around:
There are workarounds avaialble, where the user could disable the indvidual components or can customize the keys to 'unbind' F12 to do something else

Justification
This is not a critical issue and there could be UX guidelines that could be argued on both ways. The reason for raising this bug is to have those discussions so that SUMO teams have a valid answer to users

User reported
SUMO - https://support.mozilla.org/en-US/questions/976308

Fix deliverables
1. SUMO article
2. About:config setting
3. UI option

Upgrade path
If fixed, a user who is upgrading to the latest version, will have the devtools 'enabled' by default. Any new install will have the devtools 'disabled' by default

Comment 1

[Gangadhar Nittala(:gnittala)]

Sorry, forgot to add the related bugs

1. https://bugzilla.mozilla.org/show_bug.cgi?id=900061
2. https://bugzilla.mozilla.org/show_bug.cgi?id=691452

Comment 2

[Joe Walker [:jwalker]]

Thanks for the bug report. We have to weigh up the frequency with which this would be used against the cost.

I suspect that there will be few users with the sophistication to understand the benefits of turning the tools off coupled with the desire to actually turn them off. It's possible that a third party could customize Firefox with a 'no devtools' mode, although that doesn't seem like a strong case to me, given that Mozilla would like to encourage people to see the web as something to be understood and explored rather than used as a purely black box.

Am I missing a use-case for this?

Comment 3

[Dave Camp (:dcamp)]

I don't think anything has changed since we made the decision in bug 691452, please reopen if I'm wrong.

Comment 4

[Joe Walker [:jwalker]]

(In reply to Dave Camp (:dcamp) from comment #3)
> I don't think anything has changed since we made the decision in bug 691452,
> please reopen if I'm wrong.
> 
> *** This bug has been marked as a duplicate of bug 691452 ***

This request effectively made 'on' the default, so I thought it worth considering before duping, but without a strong use cases, it wouldn't be something I think we should do.

Comment 5

[Mike Kaply [:mkaply]]

> Am I missing a use-case for this?

Yes, kiosks and enterprise.

Other browsers provide ways to turn these off:

Chrome:

http://www.chromium.org/administrators/policy-list-3#DeveloperToolsDisabled

IE:

http://technet.microsoft.com/en-us/library/cc985351.aspx

Developer Tools Turn off Developer Tools User, Machine Windows Components\Internet Explorer\Toolbars

> I don't think anything has changed since we made the decision in bug 691452, please reopen if I'm wrong.

What has changed since you made the decision is that you've moved away from XUL overlays and made these more difficult to disable these.

Comment 6

[Joe Walker [:jwalker]]

It's my opinion that arguments along the lines of "to protect non-developers" (which ISTM) is the basis of the Enterprise argument isn't going to get much traction. Bug 691452 was WONTFIXed because we value people to learning about the web more than we value protecting non-developers from scarey dialogs.

The kiosk use-case makes some sense to me, although I'd like to know what is really needed here. Are you looking to make a web-kiosk that is 'safe' in some way, or is this another variation of "to protect non-developers"?

Comment 7

[Mike Kaply [:mkaply]]

(In reply to Joe Walker [:jwalker] from comment #6)
> It's my opinion that arguments along the lines of "to protect
> non-developers" (which ISTM) is the basis of the Enterprise argument isn't
> going to get much traction. Bug 691452 was WONTFIXed because we value people
> to learning about the web more than we value protecting non-developers from
> scarey dialogs.

See:
http://mike.kaply.com/2013/10/15/reframing-the-enterprise-discussion/
and
http://mike.kaply.com/2013/07/01/make-your-feature-enterprise-ready/.

I really don't understand why people don't get this. It's not about "protecting non-developers." It's not about enterprise. It's that people use browsers in ways that you guys have never seen before. The assumption that everyone should have access to Web Developer Tools is just simply wrong. Please tell me why someone needs Web Developer tools on a medical device.

> The kiosk use-case makes some sense to me, although I'd like to know what is
> really needed here. Are you looking to make a web-kiosk that is 'safe' in
> some way, or is this another variation of "to protect non-developers"?

A kiosk usually runs the browser full screen with little or no UI. You don't want someone to be able to access the developer tools because then they could hack into the kiosk (or have something unexpected happen).

There are whole websites dedicated to hacking Firefox kiosks (bringing up chrome URLs, and other things). There was even a presentation at defcon on this.

The goal would be to make it so the user wouldn't get any unexpected things when using the kiosk and to prevent hacking.

Comment 8

[Paul Rouget [:paul]]

(In reply to Mike Kaply (:mkaply) from comment #7)
> A kiosk usually runs the browser full screen with little or no UI. You don't
> want someone to be able to access the developer tools because then they
> could hack into the kiosk (or have something unexpected happen).
> 
> There are whole websites dedicated to hacking Firefox kiosks (bringing up
> chrome URLs, and other things). There was even a presentation at defcon on
> this.
> 
> The goal would be to make it so the user wouldn't get any unexpected things
> when using the kiosk and to prevent hacking.

In this case, don't use browser.xul, use another window.

Instead of disabling all the features, start from a feature-less tool.

Comment 9

[Mike Kaply [:mkaply]]

(In reply to Paul Rouget [:paul] from comment #8)
> (In reply to Mike Kaply (:mkaply) from comment #7)
> In this case, don't use browser.xul, use another window.
> 
> Instead of disabling all the features, start from a feature-less tool.

No, because there are some things from Firefox we do want, some toolbar buttons, etc.

It's much easier to customize Firefox down then it is to customize another Window up.

The goal is that when you start Firefox it's in kiosk mode. We don't want to have to start another window.

Why are you so against this concept?

Comment 10

[Paul Rouget [:paul]]

> Why are you so against this concept?

I'm not.

I guess if we had a patch that exposes an about:config pref that would disable the devtools, we'd take it.

I'm re-opening this bug because I think that the consensus is that the devtools developers don't want to work on that, but I don't see any drawback of having such a mechanism.

Comment 11

[Mike Kaply [:mkaply]]

As I pointed out in bug 939974, the preferences actually work to disable most of the developer tools.

The issue is that two of them regressed in the latest build (scratchpad and responsiveUI).

So this does mostly work. I'm just trying to figure out why two of them don't work in the new system.

Comment 12

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Mike: I agree that there should be working prefs that disable scratchpad and responsiveUI for your use-case, eg that not having them is a bug. If you had a patch that fixed those it would make this conversation a lot less theoretical.

Comment 13

[Paul Rouget [:paul]]

I was thinking… as a first step we could just bail in gDevTools.showToolbox() if devtools.enabled is false. It won't hide the devtools, but would disable them.

It's a 2 lines patch.

Comment 14

[Paul Rouget [:paul]]

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #13)
> It won't hide the devtools

I mean: it won't hide the devtools buttons and menuitems, but they would become not operational, and it would disable F12 & co.

Comment 15

[Mike Kaply [:mkaply]]

We did this via policy.

https://github.com/mozilla/policy-templates/blob/master/README.md#disabledevelopertools