Currently there's a specific pref for enabling/disabling Java while there's no such thing for e.g. Flash or QuickTime. Why not treat it in the same way? As proposed in bug 344634, this would mean another pref less in the Options dialog, while still allowing the user to enable/disable it from blessed UI (currently the Download Actions dialog; see bug 339056 and bug 19118 for separated plugin handling).
Java has been problematic in the past, and I believe it's had more security issues than most other plugins, so the checkbox has actually come in handy - in a security bulletin, it's easier to say "uncheck the Java box" than give instructions for using about:config. I understand your point about not special-casing it, though. That being said, it seems like the patch in bug 340677 (which landed on the trunk) already removed the pref - so why this bug? To ensure it stays that way? :)
I originally thought that the other plugins could be disabled through the Download Actions dialog. Apparently I was wrong. I'll keep this bug open to track the aspect of bug 340677 concerning Java (which seems to have got in without much discussion). Let's just hope that, instead of just removing UI for that pref, all plugins will be disablable through the Add-ons manager (as proposed in bug 339056). BTW: In comment #0 I obviously meant to link to bug 340677 instead of bug 344634.
Java was originally quite a different thing from plugins, which were "dumb" media players. As media players have become fully scriptable the distinction has become insignificant, as recognized by the HTML spec which deprecates <embed> and <application> in favor of calling them both <object>. But don't take away my Java pref. I'm all for treating plugins like Java (adding the ability to disable them), but not treating Java the same as we (currently) do plugins.
Please file followup bugs for the remaining issues you and I have talked about. Thanks
bah... that comment was meant for bug 339056
In branch when you go to a java site with disabled java and you decide to load the applet, it is enough to enable java and to reload the site. It doesn't require a browser restart. Please make sure that this functionality doesn't get lost.
That's not been my experience with FF2 on Windows -- if disabled I have to restart the browser after I enable Java if I want it to work.
Funny, after the third new profile it works now. Don't know exactly what actions lead to the result that it needed a browser restart. (In reply to comment #9) > That's not been my experience with FF2 on Windows -- if disabled I have to > restart the browser after I enable Java if I want it to work. > I tested the puzzles on www.jigzone.com, http://www.jigzone.com/puzzles/2007-08-07 Maybe different for sites or applets?
When I have disabled java in Options, java plugins are not present anymore in the Add-ons list after a restart. This may be a problem when Java is removed from Options for people who update from Firefox 2.x to 3.x.
(In reply to comment #8) > it is enough to enable java and to reload the site. This seems to even work for all plug-ins through the Add-ons manager now: disabling happens instantly, enabling requires a page reload. (In reply to comment #11) > java plugins are not present anymore in the Add-ons list after a restart. Treating Java the same should imply removing the pref security.enable_java and whatever code is involved.
Ria, no changes to what you are asking for are planned so it should work as you requested... it currently does from my experience though it isn't obvious in the content window. We will most assuredly provide ui to display in the add-ons mgr. java so people can enable / disable. As to whether it is still displayed as a checkbox as it is in 2.0 that is up to the user experience people, etc.
So, if we want to keep the special case handling of java as it stands now it will need to be special cased in the add-ons mgr to prevent some of ui inconsistency... other ui inconsistency would also need to be addressed... I believe fixing bug 391625 should resolve that. It would also be possible to move the same special case handling into the pref panel, have it listen for plugin changes like bug 391625, and not use the pref.
11 years ago
From a discussion on IRC the suggestion was that while the pref can remain in the backend it should be removed from the UI in favour of a link through to the addons manager plugins pane. Disabling/enabling the java plugin there should not alter the pref but should just enable/disable the plugin (this is all assuming that that is fixable).
Another option would be to have the prefpane code enumerate / disable all Java plugins.
(In reply to comment #17) > Another option would be to have the prefpane code enumerate / disable all Java > plugins. This already happens internally to the plugin code.
We wouldn't block the release for this, but it's definitely wanted clean up. The more I thought of it, the more I was of the mind that the link from Preferences to AMO should probably call out Java, but not be isolated to it: Maybe Enable / disable Java and other add-ons with the ( Manage Add-ons... ) Add-ons manager
Flags: blocking-firefox3? → blocking-firefox3-
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 506985
You need to log in before you can comment on or make changes to this bug.