Closed Bug 625220 Opened 15 years ago Closed 15 years ago

Disable Java by default in Camino 2.1

Categories

(Camino Graveyard :: Preferences, defect)

Product:
Camino Graveyard
Component:
Preferences
Version:
1.9.2 Branch
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino2.1

People

(Reporter: alqahira, Assigned: stuart.morgan+bugzilla)

References

Details

I think this might have come up in the discussion around bug 558432, but I'd like to get a bug on file about it. Given the continuing rise of Java as a vector for malware, the fact Apple's Java typically is updated more slowly and less frequently than Sun's—assuming Sun fixes the security holes and malware vector routes—(and is not being updated at all on 10.4, which we'll still support), and its relative disuse on the web, I think we should disable Java by default in 2.1 (starting with b1). Given that the old pref has gone away (i.e., Gecko doesn't read or set it), I think there's even an argument to be made to disable Java for everyone and not try to read the pref ourselves in existing profiles to migrate people appropriately; not migrating would extend the benefits of this changes to everyone, not just new profiles. Turning it back on would be a minor hassle for the people that use it (we could relnote it prominently). However, I do worry about the people who use Java to play Yahoo! and pogo.com games; as we saw with bug 607678, people weren't able to identify that it was Java involved. Further, the site UI is not good in those two cases. On pogo.com, it sends you to Sun to download, and that sends you to Apple to download Java 2 SE 5.0 Release 1 for 10.4 and later, from April, 2005. On Yahoo!, the first bullet is "make sure Java is enabled" but the help link for that item is old and just redirects you to the main Yahoo! help page, and the second bullet to download Java sends you to java.com, where the download button send you to a help page telling you to use Software Update :(
Flags: camino2.1?
I'm all for this (as previously discussed).
We should do this now. (I yearn for the day we can disable all plugins by default.)
Knowing pink, I have trouble imagining him objecting to this ;) and there's been general agreement among the rest dev team in the bug and on irc tonight, so confirming. Unlike not being able to turn Java off at all, this probably doesn't block, but we can handle that when we get there (as well as deciding whether to disable it universally or just for new profiles). Also, in case comment 0 is not clear to anyone else, the "minor hassle for the people that use it" is simply opening the Web Features pane and clicking the checkbox; though the checkbox doesn't work right now, bug 558432 is going to fix that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: camino2.1?
Target Milestone: --- → Camino2.1
I absolutely think we should definitely disable it for everyone, not just new profiles.
This will be fixed by bug 558432's patch. One caveat: we'll actually tell Gecko to disable Java when one of the following happens: 1) Gecko consults the blocklist for the Java plugin because it thinks Java has changed 2) Gecko consults the blocklist for the Java plugin because we nuked pluginreg.dat and it has to start over 3) The user toggles the Java pref 4) The user changes the hidden pref for disabling other plugins Case 2 will cover people who auto-update to 2.1. I hope manual updaters will fall into case 1, since the whole directory structure will be newly copied, but on the off chance that doesn't happen, Java will still be on for those users (although the UI will have it unchecked). Hopefully, it will be rare, people even noticing will be even rarer, and those who notice will try toggling the pref and thus fix themselves. So I don't really expect an issue here. If it looks like it is a problem though, we can explore options for a one-time broader nuke of pluginreg.dat.
Assignee: nobody → stuart.morgan+bugzilla
Smokey pointed out that my comment above is confusing; when I said "we'll actually tell Gecko to disable Java" I meant, "we'll actually sync Gecko's idea of whether Java is disabled with our pref".
(In reply to comment #5) > 1) Gecko consults the blocklist for the Java plugin because it thinks Java has > changed > > Case 2 will cover people who auto-update to 2.1. I hope manual updaters will > fall into case 1, since the whole directory structure will be newly copied, but > on the off chance that doesn't happen, Java will still be on for those users > (although the UI will have it unchecked). Something in the build (packaging?) process causes everything to be written with that morning's timestamp—the bundles, the files, everything—so I think we're going to be safe here.
Fixed by checkin for bug 558432. Hopefully the screaming will be minimal ;)
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(In reply to comment #7) > (In reply to comment #5) > > 1) Gecko consults the blocklist for the Java plugin because it thinks Java has > > changed > > > > Case 2 will cover people who auto-update to 2.1. I hope manual updaters will > > fall into case 1, since the whole directory structure will be newly copied, but > > on the off chance that doesn't happen, Java will still be on for those users > > (although the UI will have it unchecked). > > Something in the build (packaging?) process causes everything to be written > with that morning's timestamp—the bundles, the files, everything—so I think > we're going to be safe here. This turned out not to trigger nsPluginHost's (re)check after all, so we filed bug 626579.
You need to log in before you can comment on or make changes to this bug.