Closed
Bug 506985
Opened 15 years ago
Closed 15 years ago
remove java-specific preferences from Firefox UI, hidden prefs
Categories
(Firefox :: Settings UI, defect)
Firefox
Settings UI
Tracking
()
RESOLVED
FIXED
Firefox 3.7a1
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta1-fixed |
People
(Reporter: jaas, Assigned: jaas)
References
Details
(Keywords: useless-UI, user-doc-complete, verified1.9.2, Whiteboard: [killthem])
Attachments
(2 files, 1 obsolete file)
23.04 KB,
patch
|
jst
:
review+
jst
:
superreview+
faaborg
:
ui-review+
beltzner
:
approval1.9.2+
|
Details | Diff | Splinter Review |
23.36 KB,
patch
|
Details | Diff | Splinter Review |
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.
Add a null check.
Attachment #391154 -
Attachment is obsolete: true
Attachment #391156 -
Flags: review?(jst)
Comment 3•15 years ago
|
||
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+
Updated•15 years ago
|
Attachment #391156 -
Flags: ui-review?(beltzner) → ui-review+
Comment 4•15 years ago
|
||
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.
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?
pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/46daa864e04c
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 8•15 years ago
|
||
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?
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•15 years ago
|
Keywords: relnote,
user-doc-needed
Updated•15 years ago
|
Attachment #391156 -
Flags: approval1.9.2? → approval1.9.2+
Comment 11•15 years ago
|
||
Comment on attachment 391156 [details] [diff] [review] fix v1.1 a192=beltzner
Updated•15 years ago
|
Whiteboard: [killthem]
Assignee | ||
Comment 12•15 years ago
|
||
pushed to mozilla-1.9.2 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/49ddd7fe184f
Keywords: fixed1.9.2
Comment 14•15 years ago
|
||
(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.
Comment 15•15 years ago
|
||
(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•15 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.
Updated•15 years ago
|
status1.9.2:
--- → beta1-fixed
Keywords: fixed1.9.2
Comment 17•15 years ago
|
||
(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.
Updated•15 years ago
|
Keywords: useless-UI
Comment 18•15 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.
Comment 19•15 years ago
|
||
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•15 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•15 years ago
|
||
Bug 513979 is about pref migration, please move any further discussion of that over there.
Comment 22•15 years ago
|
||
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
Comment 23•15 years ago
|
||
Litmus tests have been updated to reflect this change.
Flags: in-litmus+
Target Milestone: --- → Firefox 3.7a1
Comment 25•15 years ago
|
||
user-doc-complete Updated: https://support.mozilla.com/en-US/kb/Accessibility https://support.mozilla.com/en-US/kb/How+to+turn+off+Java+applets https://support.mozilla.com/en-US/kb/Options+window+-+Content+panel https://support.mozilla.com/en-US/kb/Using+the+Java+plugin+with+Firefox+
Keywords: user-doc-needed → user-doc-complete
Comment 26•14 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?
Comment 27•14 years ago
|
||
Nicholas, can you please file a new bug so we can investigate that? Please give more information about your system and CC me. Thanks.
Depends on: 558432
You need to log in
before you can comment on or make changes to this bug.
Description
•