Closed Bug 594482 Opened 14 years ago Closed 14 years ago

Java applets broken with content policies (NoScript, Adblock Plus, GreaseMonkey...)

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(blocking2.0 betaN+)

Status:
VERIFIED FIXED
Milestone:
mozilla2.0b8
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: jamesrome, Assigned: smichaud)

References

(
URL
)

Details

(Keywords: regression, relnote)

Attachments

(4 files, 1 obsolete file)

What I see
63.19 KB, image/png
Details
Minimal content policy for testing
1.40 KB, application/x-xpinstall
Details
no 32-bit mode checkbox
88.50 KB, image/png
Details
Fix rev1 (restore missed calls to NPP_SetWindow())
14.58 KB, patch
jaas
: review+
benjamin
: review+
Details | Diff | Splinter Review
Attached image What I see —
Firefox 4.0 beta 4 and beta 5 do not fully execute Java plugins. For example, go to http://whisper.cs.utk.edu:8234/, and only a coffee cup appears. There are no errors in the Java console. This page works in Firefox 3.6. See attached screen shot. I tried this on two different machines.
Yesterday, I tried to repro this on my 10.6 machine in the lab and I did see the content. And I cannot repro on 10.5 either.
I looked further. Java does work if I start the browser in safe mode. So it has to be an add-on. I will selectively disable them and see.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
It i NoScript! I disabled it, and Java worked.
The fact that an add-on triggers the issue (by accessing the applet in some way) doesn't mean that it is an add-on bug. Neither NoScript nor Adblock Plus (which this bug was also reported for) can do anything that would prevent an applet from initializing (mind you: the applet isn't blocked, the coffee cup appears - but things don't get any further than that). Reopening. Btw, Reporter is using Java 1.6.0_21 according to info in my bug report.
Blocks: abp
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
I asked James to install my minimal content policy (the usual suspect) - it didn't trigger the problem. Must be some more complicated interaction then.
Summary: Java applets do not work any more → Java applets do not work any more if NoScript or Adblock Plus are installed
I seem to have one more piece of information that is missing from this bug report: we are talking about OS X 10.6.4.
Summary: Java applets do not work any more if NoScript or Adblock Plus are installed → [10.6] Java applets do not work any more if NoScript or Adblock Plus are installed
It seems to be an issue with Google Chrome as well... on my system I can only use Safari for Java applets on the web...
I can confirm this on OS X 10.6.4 with Firefox 4.0b6. Safari, Chrome, Opera and FF 3.6 are all displaying the java applet okay. You need to disable noscript and adblock in order to view java applets on Firefox 4.0.
One more user reported this issue, GreaseMonkey is apparently triggering it as well - that's one more add-on using content policies.
Apple saya that the cause is definitely NoScript.
James, this issue is *triggered* by any extension using content policies - Adblock Plus, NoScript, GreaseMonkey. But using content policies shouldn't have the effect of breaking Java.
Go discuss it with Apple Bug ID# 8405379
blocking2.0: --- → ?
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Summary: [10.6] Java applets do not work any more if NoScript or Adblock Plus are installed → Java applets broken with content policies (NoScript, Adblock Plus, GreaseMonkey...)
Target Milestone: --- → mozilla2.0
Wladimir, I'd be interested in a log of the content policy calls you get running the testcase, if your minimal content policy can log those.
Since this doesn't happen with a minimal content policy, I'm going to clear the nomination for now. Please renominate if we can determine that there's a platform bug here.
blocking2.0: ? → ---
Boris, I don't have access to a Mac myself so I cannot run the testcase. Adding a dump() call to the minimal content policy is something I can easily do however.
If you're willing to do that and if James is willing to run the result, that would be great. Alternately, I would be happy to run it myself, if someone points me to a page that shows the problem.
Wladimir, can you confirm comment #9, where you wrote GreaseMonkey does trigger this problem? GM has an almost-minimal shouldLoad() implementation, touching only the location and origin URI arguments (i.e. no DOM manipulation at all via context argument, which has been a common issue in the past). GM triggering while the minimal content policy doesn't sounds weird to me...
I guess I know why the bug wasn't reproducible with my minimal content policy - I forgot to update it for the chrome registration changes on trunk so it wasn't doing anything. Updated version attached, it will also log the calls to console.
Boris, James mentioned a URL in the bug description, maybe you will be able to reproduce there.
URL: http://whisper.cs.utk.edu:8234/
> Created attachment 481488 [details] > Minimal content policy for testing I can reproduce the problem with this attachment. Tested with the latest nightly (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101007 Firefox/4.0b8pre), clean profile with no other extensions and the URL in this bug
I will be glad to test any fix.
Re-requesting blocking2.0 since it is apparently reproducible with the minimal content policy after all.
blocking2.0: --- → ?
Status: REOPENED → NEW
Hardware: x86 → All
Anyone know what the regression range is?
Keywords: regressionwindow-wanted
Regressed between the builds 10012303 and 10012403: PASS: http://hg.mozilla.org/mozilla-central/rev/6f48ddc83ea7 FAIL: http://hg.mozilla.org/mozilla-central/rev/86a6b2485640 Check-ins: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6f48ddc83ea7&tochange=86a6b2485640 I suspect: "Bug 541018 - Pointer to NP_CGContext should be NULL in Cocoa NPAPI event model. r=smichaud"
Keywords: regressionwindow-wanted → regression
For what it's worth, I can definitely reproduce on the url from comment 0. And I can confirm via local bisect that this is a regression from bug 541018. I do think this needs to block....
blocking2.0: ? → beta8+
Keywords: relnote
I feel naked using FF4 without NoScript. Please don't keep pushing off fixing this.
Can we retest this with latest nightly?
I'll be glad to test it, but has anything changed that would fix this?
I tested it. No change on 4.0b8pre nightly. Wishful thinking will not fix this!
OS: Mac OS X → Windows 7
Please put Mac OS X back as an affected platform.
OS: Windows 7 → Mac OS X
James and/or Boris, here are a couple more things to try. I can't guarantee they'll make any difference, but they may make it a little easier to understand what's going on here: 1) Test with Apple's most recent Java update (which came out very recently): Java for Mac OS X 10.6 Update 3 (http://support.apple.com/kb/dl972) Java for Mac OS X 10.5 Update 8 (http://support.apple.com/kb/DL971) 2) If you're running on OS X 10.6.X, test in 32-bit mode: a) Right-click on today's Minefield nightly's distro and choose Get Info. b) Check the "Open in 32-bit mode" box. c) Start Minefield and do your test.
Steven, does that mean that you can't reproduce the issue on your setup?
Yes, I have the new Java update. But there is no "open in 32-bit mode" checkbox. See attachment.
Attached image no 32-bit mode checkbox —
Boris> Steven, does that mean that you can't reproduce the issue on Boris> your setup? It means I haven't yet had the time to test :-( James> no 32-bit mode checkbox Are you running OS X 10.5.8? (I'd assumed you're on OS X 10.6.4.)
I am on 10.6.4 ans see no checkbox.
(In reply to comment #31) > > 1) Test with Apple's most recent Java update (which came out very > recently): > > 2) If you're running on OS X 10.6.X, test in 32-bit mode: > Tested with latest Java update and 32bit on 10.6.x, no luck. Still doesn't work Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101026 Firefox/4.0b8pre
James> I am on 10.6.4 and see no checkbox. Then you must have a 32-bit CPU. Thanks Onno, for your test. I'll test myself when I have time -- probably later this week.
Assignee: nobody → smichaud
Status: NEW → ASSIGNED
I have a MacPro with dual 4-cpu Xeons. Definitely 64-bits.
> I have a MacPro with dual 4-cpu Xeons. Definitely 64-bits. Then you presumably weren't testing with today's Minefield nightly, available here: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-10-26-03-mozilla-central/firefox-4.0b8pre.en-US.mac64.dmg
Nope. That is the version I downloaded. I re-downloaded from your link and still do not see a 32-64-bit checkbox. I know that I do use a mixed-mode kernel. Anyhow, if I am running 32-bit mode, it does not run Java still if NoScript is on.
I looked in Activity Monitor. Minefield is running in 64 bits. And no choice in the info screen. I guess that's a bug too.
blocking2.0: beta8+ → betaN+
This seems to be getting pushed back. Please fix it for beta 8. 7 is about out. Is anyone working on this?
The check box is here Applications > Utilities > Java Preferences.app. It is really not a check box you simply drag which one you want to the top (32/64). I ran a test at javatester.org using FF4b7 on OSX 10.6.5 with Java Update 3 in 32 bit mode and it failed. Below is the detail I got from the site on the failure. Note I had ABP, NS and GM all disabled. Also, the Java Plugin doesn't show in about:plugins Java Plug-in 1.6.0_22 Using JRE version 1.6.0_22-b04-307-10M3261 Java HotSpot(TM) Client VM User home directory = /Users/robertjanc ---------------------------------------------------- c: clear console window f: finalize objects on finalization queue g: garbage collect h: display this help message l: dump classloader list m: print memory usage o: trigger logging q: hide console r: reload policy configuration s: dump system and deployment properties t: dump thread list v: dump thread stack x: clear classloader cache 0-5: set trace level to <n> ---------------------------------------------------- load: class JavaVersionDisplayApplet.class not found. java.lang.ClassNotFoundException: JavaVersionDisplayApplet.class at sun.plugin2.applet.Applet2ClassLoader.findClass(Applet2ClassLoader.java:230) at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Plugin2ClassLoader.java:249) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Plugin2ClassLoader.java:179) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Plugin2ClassLoader.java:160) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Plugin2ClassLoader.java:686) at sun.plugin2.applet.Plugin2Manager.createApplet(Plugin2Manager.java:2990) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Plugin2Manager.java:1481) at java.lang.Thread.run(Thread.java:680) Caused by: java.net.ConnectException: Operation not permitted at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432) at java.net.Socket.connect(Socket.java:529) at sun.net.NetworkClient.doConnect(NetworkClient.java:161) at sun.net.www.http.HttpClient.openServer(HttpClient.java:394) at sun.net.www.http.HttpClient.openServer(HttpClient.java:529) at sun.net.www.http.HttpClient.<init>(HttpClient.java:233) at sun.net.www.http.HttpClient.New(HttpClient.java:306) at sun.net.www.http.HttpClient.New(HttpClient.java:323) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:975) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:916) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379) at sun.plugin2.applet.Applet2ClassLoader.getBytes(Applet2ClassLoader.java:593) at sun.plugin2.applet.Applet2ClassLoader.access$000(Applet2ClassLoader.java:52) at sun.plugin2.applet.Applet2ClassLoader$1.run(Applet2ClassLoader.java:203) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin2.applet.Applet2ClassLoader.findClass(Applet2ClassLoader.java:200) ... 8 more Exception: java.lang.ClassNotFoundException: JavaVersionDisplayApplet.class
Robert, what you report is unrelated, and possibly not our bug (does it also happen in Safari?) I was talking about running Firefox in 32-bit mode (as a test). You're talking about running Java in 32-bit mode.
Sorry if I misread. Safari works fine and so does FF3.6.12. FYI - Neither Chrome or Opera (latest versions) work.
Chrome 7.0.517.44 on OS X 10.6.5 works fine at http://miranda.ctd.anl.gov:7123/
I'm really embarrassed. Once I allowed Java Applets to make outgoing connections in my Intego x6 virus software, javatester.org works for Chrome. However, it doesn't work in FF4b7 and in that test in looking at the log for Intego, Java never tried to make an outbound connection. For some reason it looks like FF4b7 can't "see" the JavaVM. Hope this is helpful; don't want to clutter this thread.
I can confirm that FF4b7 breaks the WebEx plug-in as well; I believe it worked fine in b6, but am not 100% sure as I can't remember which beta version I was on prior to the b7 upgrade. I can state that it was working at some point prior to b7.
Scott: this bug is only for cases where java applets are broken by add-ons that implement content policies. If you're seeing other broken plugins, please file separate bugs.
(In reply to comment #49) > I can confirm that FF4b7 breaks the WebEx plug-in as well...[snip] WebEx plug-in works with Fx4b7 in 32-bit mode. Previous betas had separate 32/64-bit Mac builds, now there's a single combined build. It's indeed unrelated to this bug, hopefully Cisco will add 64-bit WebEx support for Fx4. FWIW re this bug: Flashblock plug-in may alleviate the pain of ad-enabled browsing with Fx4 betas until this is fixed.
Attached patch Fix (obsolete) — — Splinter Review
Turns out this problem is caused by a subtle bug in Apple's Java Plugin2: Instantiating a JavaScript-based content policy causes NPP_GetValue(NPPVpluginScriptableNPObject) to be called on a plugin instance before the first time NPP_SetWindow() is called on it. Doing this confuses Java Plugin2. Before the patch for bug 541018 landed, Java Plugin2 was able to recover from its confusion by looking at the NP_CGContext structure passed to the plugin by subsequent calls to NPP_SetWindow(). But that patch stopped providing this information. The solution is very straightforward: If need be we call NPP_SetWindow() ourselves before calling NPP_GetValue(). For the record, the "premature" call to NPP_GetValue(NPPVpluginScriptableNPObject) is triggered by the following line: http://hg.mozilla.org/mozilla-central/annotate/01bdda1252f0/content/base/src/nsObjectLoadingContent.cpp#l1247 A tryserver build will follow in a few hours.
Attachment #494587 - Flags: review?(joshmoz)
Steven, just tested the build on a 32bit mac and java is now working for me. Thanks!
Yup. Java works for me also with NoScript enabled. I just used the default for everything, so not sure if it is 32- or 64-bits. I have never been able to find how to make that choice. I also reported this to Apple on bug 8405379
http://www.screencast-o-matic.com/create That link still does not work on today's nightly (Minefield with NoScript enabled: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101202 Firefox/4.0b8pre) on MacOS X 10.6.5.
It does work with the link in comment 54. I hope the official beta 8 build incorporates the patch!
Does not work for me. I get "additional plugins are required for this page", when trying to install those plugins "no suitable plugins are found."
Worked for me on http://javatester.org/ with NoScript, Adblock Plus and Greasemonkey all installed and active. OSX 10.6.5 in 64 bit mode.
(In reply to comment #59) > Does not work for me. I get "additional plugins are required for this page", > when trying to install those plugins "no suitable plugins are found." Sounds like a different, unrelated bug.
Comment on attachment 494587 [details] [diff] [review] Fix Steven is going to investigate if/why the patch that exposed this problem may have changed the timing of NPP_SetWindow calls rather than just changing the pointer to a structure filled with NULL values to NULL pointer, as intended. I don't think the patch in bug 541018 meant to change any timing.
Attachment #494587 - Flags: review?(joshmoz)
My patch consistently triggers a bunch of test failures on Linux, all of which have the following error in common: ###!!! [Child][RPCChannel] Error: Channel error: cannot send/recv (By "consistently" I mean in two different tryserver runs -- one last night and one this morning. So this is presumably not just test flakiness.) Even if I don't change my patch as a result of the investigation Josh asked me to do, I may still need to limit its application -- possibly only to windowless plugins on Windows and Linux.
Alas, if you allow the updater to update this patched build, the fix disappears. Is there any change of getting this into beta 8 before it is released? It is not yet in the nightly builds.
A patch for this is not likely to be in beta 8. We'll fix it as soon as we can.
On the patched build, I am unable to open Minefield/preferences. Is this a side effect of this patch?
> On the patched build, I am unable to open Minefield/preferences. Is > this a side effect of this patch? No. It's possible your problem was caused by an (unrelated) short-term bug that has since been fixed. But it's more likely you have some sort of local problem. Do you also see this with today's Minefield nightly? If so try with a fresh profile. If you still see the problem *please open a new bug* :-)
Preferences still work with 3.6, so I think my profile is OK.
The problem is AdBlock Plus. If I disable that, preferences work again. But it does work with NoScript and Download StatusBar enabled.
Oh, and it also stopped the add-ons manager window from appearing.
Josh, you were right -- your patch for bug 541018 *did* change the timing of the first call to NPP_SetWindow() made on a plugin, and that change *did* trigger this bug. This is still a bug in Apple's Java Plugin2 ... but not a particularly bad one. And in any case it has an easy workaround. The problem is that there are a bunch of places in Mozilla code where NPP_SetWindow() is only called if NPWindow.window is non-NULL. But the patch for bug 541018 makes this always NULL when the plugin uses the CoreGraphics drawing mode (as do Java Plugin2 and many other plugins). My solution is to make these calls to NPP_SetWindow() from nsIPluginInstanceOwner. Besides fixing this bug, this change also neatens up our code -- now (with my patch) there's exactly one place where we decide how (and whether) to call NPP_SetWindow() (rather than several as previously). The missed call to NPP_SetWindow() that triggers this bug is at the following line: http://hg.mozilla.org/mozilla-central/annotate/e52f4987ec94/modules/plugin/base/src/nsPluginHost.cpp#l1088 But (as I said) there are a bunch of other places where calls to NPP_SetWindow() are missed. I fixed all the ones I could find (and I think I found them all). So other (OSX-specific) plugin bugs may also be fixed by my patch. (Following up comment #63) > ###!!! [Child][RPCChannel] Error: Channel error: cannot send/recv My hunch is that this error was caused (when using OOPP) by doing a parent-side call to NPP_SetWindow() (i.e. to nsIPluginInstanceOwner::SetWindow()) from client-side code (nsNPAPIPluginInstance::GetValueFromPlugin()). As far as I can tell, my current patch no longer makes this mistake (it always calls nsIPluginInstanceOwner::SetWindow() from parent-side code). I'm currently doing some tryserver builds. My results on Linux should tell me whether or not I'm right.
Attachment #494587 - Attachment is obsolete: true
Attachment #495171 - Flags: review?(joshmoz)
(In reply to comment #62) > rather than just changing the pointer to a structure filled with > NULL values to NULL pointer, as intended. (From comment #53) > Before the patch for bug 541018 landed, Java Plugin2 was able to > recover from its confusion by looking at the NP_CGContext structure > passed to the plugin by subsequent calls to NPP_SetWindow(). But > that patch stopped providing this information. I forgot to mention that, before the patch for bug 541018 landed, NPWindow.window did indeed (in CoreGraphics mode) contain a bunch of NULL pointers. So it would have been a little strange if these NULL pointers constituted the "information" that Java Plugin2 used to "recover from its confusion".
Here's a tryserver build made with my patch from comment #71: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/smichaud@pobox.com-e56c146597fd/tryserver-macosx64/firefox-4.0b8pre.en-US.mac64.dmg Please try it out. The tryserver tests (which ran on all platforms) had no non-spurious failures (and only one failure of any kind) -- so the "channel error" problem seems to have been fixed.
Tested the build in #73. Java is OK. But if I enable the Adblock Plus filter set updater, Preferences will not appear. AdBlock Plus itself is OK.
> But if I enable the Adblock Plus filter set updater, Preferences > will not appear. Does this also happen without my patch (i.e. in today's Minefield nightly)?
Attachment #495171 - Flags: review?(joshmoz)
Attachment #495171 - Flags: review?(benjamin)
Attachment #495171 - Flags: review+
Steven, I tested the build in comment #73 and java is working for me on a 32bit macbook pro. Adblock plus is turned on and working. Preferences are working as well, I'm not seeing any problems there.
Yup. AdBlock Updater kills preferences in the unpatched Minefield, so this patch is ready to go as far as I am concerned.
Comment on attachment 495171 [details] [diff] [review] Fix rev1 (restore missed calls to NPP_SetWindow()) Please make the interface non-scriptable. nsIPluginInstanceOwner is non-scriptable, and all the C++ goop in it would make anyone calling it from script crash anyway.
Attachment #495171 - Flags: review?(benjamin) → review+
Comment on attachment 495171 [details] [diff] [review] Fix rev1 (restore missed calls to NPP_SetWindow()) Landed on the trunk with bsmedberg's change: http://hg.mozilla.org/mozilla-central/rev/b1b57869cb43
Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
so please let us know when the nightlies have this in them, and if beta 8 will.
Depends on: 618487
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110107 Firefox/4.0b9pre
Status: RESOLVED → VERIFIED
Target Milestone: mozilla2.0 → mozilla2.0b8
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: