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

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

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?

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

(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.

> 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.

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"?

(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.

(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.

(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?

> 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.

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.

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.

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.

(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.