|Summary:||Java applets should be blocked when plugins are blocked (in Chromium, at least)|
|Product:||WebKit||Reporter:||Bernhard Bauer <bauerb>|
|Severity:||Normal||CC:||andersca, brettw, commit-queue, darin, fishd|
|Version:||528+ (Nightly build)|
|OS:||OS X 10.5|
Description Bernhard Bauer 2010-07-29 09:41:56 PDT
After removing click-to-play in Chromium, Java applets aren't blocked when plugins are disabled in the content setting (http://crbug.com/50506). Turns out, this was already broken some time before click-to-play landed, namely since http://trac.webkit.org/changeset/60178. Even before that, applets were only blocked pretty much as a side effect of the code removed in that revision. Patch forthcoming.
Comment 1 Bernhard Bauer 2010-07-29 09:49:01 PDT
Created attachment 62964 [details] Check if plugins are allowed before creating a Java applet
Comment 2 Bernhard Bauer 2010-07-29 09:53:53 PDT
Bonus: with this patch, you also get the plugins blocked bubble (you didn't before).
Comment 3 Darin Adler 2010-07-29 11:23:22 PDT
Comment on attachment 62964 [details] Check if plugins are allowed before creating a Java applet This is not a Chromium-specific patch. Do all platforms want to block Java if plug-ins are blocked?
Comment 4 Darin Fisher (:fishd, Google) 2010-07-29 14:25:13 PDT
Comment on attachment 62964 [details] Check if plugins are allowed before creating a Java applet R+CQ=me No other ports override allowPlugins to block plugins on a per-frame basis. Other ports use the global settings to block Java, etc. It seems appropriate to me to treat Java as a plugin. (It is an ordinary NPAPI plugin these days, at least on Windows.)
Comment 5 WebKit Commit Bot 2010-07-29 15:09:58 PDT
Comment on attachment 62964 [details] Check if plugins are allowed before creating a Java applet Clearing flags on attachment: 62964 Committed r64311: <http://trac.webkit.org/changeset/64311>
Comment 6 WebKit Commit Bot 2010-07-29 15:10:03 PDT
All reviewed patches have been landed. Closing bug.