remove java-specific preferences from Firefox UI, hidden prefs

RESOLVED FIXED in Firefox 3.7a1

Status

()

RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: jaas, Assigned: jaas)

Tracking

({useless-UI, user-doc-complete, verified1.9.2})

Trunk
Firefox 3.7a1
useless-UI, user-doc-complete, verified1.9.2
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus +

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

(Whiteboard: [killthem])

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

10 years ago
It would be best to minimize special-casing of Java capabilities and treat Java as much like any other addon as possible. To that end I think we should remove Java-specific preferences from the Firefox UI and hidden prefs. This means removing the "Enable Java" checkbox from Firefox's "Content" prefs and removing the "security.enable_java" pref altogether. Whether or not Java is enabled would simply be based on the Java plugin's availability as an addon/plugin.
(Assignee)

Comment 1

10 years ago
Posted patch fix v1.0 (obsolete) — Splinter Review
(Assignee)

Comment 2

10 years ago
Posted patch fix v1.1Splinter Review
Add a null check.
Attachment #391154 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Attachment #391156 - Flags: review?(jst)
Comment on attachment 391156 [details] [diff] [review]
fix v1.1

Looks good to me. Requesting ui review here since we're changing (removing) ui.
Attachment #391156 - Flags: ui-review?(beltzner)
Attachment #391156 - Flags: superreview+
Attachment #391156 - Flags: review?(jst)
Attachment #391156 - Flags: review+
Attachment #391156 - Flags: ui-review?(beltzner) → ui-review+
Comment on attachment 391156 [details] [diff] [review]
fix v1.1

Removing this pref cleans up the organization of our UI a bit.  Really the content prefpane should only apply to the open Web content that Firefox renders, and all options to enable or disable a plugin should be handled by the add-ons manager.  So just as we shouldn't have a "enable flash" or "enable silverlight" check boxes on the content pref pane, we shouldn't have a special check box for Java.  Additionally, Josh points out that this check box doesn't sync with the existence of a Java plugin, so users may be confused that they have "enable Java" checked, but Java doesn't work since no plugin is installed.  Only downsides are UI consistency and having to change existing documentation, which is worth the cost of cleaning this up.
(Assignee)

Comment 5

10 years ago
Comment on attachment 391156 [details] [diff] [review]
fix v1.1

I'd really like to see this in 1.9.2. This is part of our push to normalize the Java plugin situation as quickly as possible. See comment here:

https://bugzilla.mozilla.org/show_bug.cgi?id=479024#c20
Attachment #391156 - Flags: approval1.9.2?
(Assignee)

Comment 7

10 years ago
pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/46daa864e04c
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
What happens to users who currently have Java disabled via this pref?

Is the plugin already disabled in the addon manager, or will this patch cause it to be reenabled until they go there to disable it again?
(Assignee)

Comment 9

10 years ago
There is no migration, I don't think the added complexity is worth it. We should just leave the pref in the dust. Users who had Java disabled will have to disable any Java plugins via the addons manager.

Firefox 3.6 and higher only support the new NPAPI Java plugin which is so much improved that there are fewer reasons than ever to want to disable Java in the first place.

Updated

10 years ago
Keywords: relnote, user-doc-needed
Duplicate of this bug: 513152
Attachment #391156 - Flags: approval1.9.2? → approval1.9.2+
Whiteboard: [killthem]
(Assignee)

Comment 12

10 years ago
pushed to mozilla-1.9.2

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/49ddd7fe184f
Keywords: fixed1.9.2

Updated

10 years ago
Duplicate of this bug: 344638
(In reply to comment #9)
> There is no migration, I don't think the added complexity is worth it. We
> should just leave the pref in the dust. Users who had Java disabled will have
> to disable any Java plugins via the addons manager.

I share dolske's concern. This means users who had security concerns about Java and disabled it will have it silently enabled and be vulnerable. One major reason for running with an insecure old Java is because it's required for intranet sites -- the only safe thing to do is to disable the plugin while browsing the public web. The user might not even be able to uninstall Java, and have no choice but to disable it.

> Firefox 3.6 and higher only support the new NPAPI Java plugin which is so much
> improved that there are fewer reasons than ever to want to disable Java in the
> first place.

The API has nothing to do with any reasons people want to disable Java. I know of absolutely no-one who disabled Java because of OJI. You'd want to disable Java because it's a huge complex additional attack surface you may not need, or because of the resources it consumes when some ad you didn't want to see in the first place fired it up, or because your workplace admin has installed an old version you can't change and hasn't gotten around to updating your machine.
(In reply to comment #14)
> I share dolske's concern. This means users who had security concerns about Java
> and disabled it will have it silently enabled and be vulnerable.

Which would be particularly bad for a minor update. :(
(Assignee)

Comment 16

10 years ago
(In reply to comment #14)
> The API has nothing to do with any reasons people want to disable Java. I know
> of absolutely no-one who disabled Java because of OJI. You'd want to disable
> Java because it's a huge complex additional attack surface you may not need, or
> because of the resources it consumes when some ad you didn't want to see in the
> first place fired it up, or because your workplace admin has installed an old
> version you can't change and hasn't gotten around to updating your machine.

You say that the API has nothing to do with the reasons people disable Java, then you cite two reasons that are directly related to the API change. Moving off of OJI/XPCOM/LiveConnect greatly reduces attack surface and improves resource consumption, so how is the API not related to the reasons you say people disable Java?

What you're left with is reasons that apply equally to all plugins.
status1.9.2: --- → beta1-fixed
Keywords: fixed1.9.2
(In reply to comment #16)
> You say that the API has nothing to do with the reasons people disable Java,
> then you cite two reasons that are directly related to the API change.

People who disable Java are generally not doing it for the incremental risk and resource usage due to our OJI layer. But it doesn't really matter _why_ they turned it off, they're going to be pissed to find out we ignored their express wishes. Doubly so if they think they did it for security reasons.

> What you're left with is reasons that apply equally to all plugins.

What? Are we reenabling other plugins users have disabled, too? If we are then I'll argue against that as well.
Keywords: useless-UI

Comment 18

10 years ago
It does not matter _why_ someone disabled Java, only _that_ they did. If you offer users a choice, you ought to respect it. Changes of this magnitude need to be brought to the users' attention.
I agree with comment 18.  The enabled or disabled state should be respected regardless of moving from one plugin type to another or from one version to another, for example, admins wouldn't want things that are set as disabled on purpose to be automatically turned on again.
(Assignee)

Comment 20

10 years ago
I checked in a followup fix removing a member variable declaration I forgot to remove in the original patch.

http://hg.mozilla.org/mozilla-central/rev/bdec1ecda678
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5ed94d308f16
(Assignee)

Comment 21

10 years ago
Bug 513979 is about pref migration, please move any further discussion of that over there.
verified with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a2pre) Gecko/20090911 Namoroka/3.6a2pre and equivalent Mac build
Keywords: verified1.9.2
Litmus tests have been updated to reflect this change.
Flags: in-litmus+
Target Milestone: --- → Firefox 3.7a1
Added relnote, removing tag.
Keywords: relnote

Comment 26

9 years ago
As a daily user, I'm a bit miffed that Java was suddenly disabled when I downloaded FF 3.6 RC1.  My corporate Documentum site stopped working with firefox and this is a nasty surprise in the enterprise.  Should the Java addon installed by default?
Nicholas, can you please file a new bug so we can investigate that? Please give more information about your system and CC me. Thanks.
You need to log in before you can comment on or make changes to this bug.