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

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[James Rome]

Attachment: 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.

Comment 1

[Marcia Knous [:marcia]]

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.

Comment 2

[James Rome]

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.

Comment 3

[James Rome]

It i NoScript! I disabled it, and Java worked.

Comment 4

[Wladimir Palant]

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.

Comment 5

[Wladimir Palant]

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.

Comment 6

[Wladimir Palant]

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.

Comment 7

[Goffredo Marocchi]

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...

Comment 8

[seysayux]

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.

Comment 9

[Wladimir Palant]

One more user reported this issue, GreaseMonkey is apparently triggering it as well - that's one more add-on using content policies.

Comment 10

[James Rome]

Apple saya that the cause is definitely NoScript.

Comment 11

[Wladimir Palant]

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.

Comment 12

[James Rome]

Go discuss it with Apple Bug ID# 8405379

Comment 13

[Boris Zbarsky [:bzbarsky]]

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.

Comment 14

[Benjamin Smedberg]

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.

Comment 15

[Wladimir Palant]

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.

Comment 16

[Boris Zbarsky [:bzbarsky]]

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.

Comment 17

[Giorgio Maone [:ma1]]

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...

Comment 18

[Wladimir Palant]

Attachment: Minimal content policy for testing

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.

Comment 19

[Wladimir Palant]

Boris, James mentioned a URL in the bug description, maybe you will be able to reproduce there.

Comment 20

[Onno Witvliet]

> 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

Comment 21

[James Rome]

I will be glad to test any fix.

Comment 22

[Wladimir Palant]

Re-requesting blocking2.0 since it is apparently reproducible with the minimal content policy after all.

Comment 23

[Benjamin Smedberg]

Anyone know what the regression range is?

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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"

Comment 25

[Boris Zbarsky [:bzbarsky]]

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....

Comment 26

[James Rome]

I feel naked using FF4 without NoScript. Please don't keep pushing off fixing this.

Comment 27

[Mike Beltzner [:beltzner, not reading bugmail]]

Can we retest this with latest nightly?

Comment 28

[James Rome]

I'll be glad to test it, but has anything changed that would fix this?

Comment 29

[James Rome]

I tested it. No change on 4.0b8pre nightly.
Wishful thinking will not fix this!

Comment 30

[seysayux]

Please put Mac OS X back as an affected platform.

Comment 31

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 32

[Boris Zbarsky [:bzbarsky]]

Steven, does that mean that you can't reproduce the issue on your setup?

Comment 33

[James Rome]

Yes, I have the new Java update. But there is no "open in 32-bit mode" checkbox. See attachment.

Comment 34

[James Rome]

Attachment: no 32-bit mode checkbox

Comment 35

[Steven Michaud [:smichaud] (Retired)]

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.)

Comment 36

[James Rome]

I am on 10.6.4 ans see no checkbox.

Comment 37

[Onno Witvliet]

(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

Comment 38

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 39

[James Rome]

I have a MacPro with dual 4-cpu Xeons. Definitely 64-bits.

Comment 40

[Steven Michaud [:smichaud] (Retired)]

> 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

Comment 41

[James Rome]

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.

Comment 42

[James Rome]

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.

Comment 43

[James Rome]

This seems to be getting pushed back. Please fix it for beta 8. 7 is about out. Is anyone working on this?

Comment 44

[RobertJ]

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

Comment 45

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 46

[RobertJ]

Sorry if I misread. Safari works fine and so does FF3.6.12.

FYI - Neither Chrome or Opera (latest versions) work.

Comment 47

[James Rome]

Chrome 7.0.517.44 on OS X 10.6.5 works fine at
http://miranda.ctd.anl.gov:7123/

Comment 48

[RobertJ]

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.

Comment 49

[Scott Hardin]

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.

Comment 50

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 51

[Michal Urban]

(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.

Comment 53

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix

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.

Comment 54

[Steven Michaud [:smichaud] (Retired)]

Here's a tryserver build made with my patch from comment #53:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-4128f0237aa4/tryserver-macosx64/firefox-4.0b8pre.en-US.mac64.dmg

Please try it out!

Comment 55

[Ryan]

Steven, just tested the build on a 32bit mac and java is now working for me.  Thanks!

Comment 56

[James Rome]

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

Comment 57

[Goffredo Marocchi]

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.

Comment 58

[James Rome]

It does work with the link in comment 54.
I hope the official beta 8 build incorporates the patch!

Comment 59

[seysayux]

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."

Comment 60

[RobertJ]

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.

Comment 61

[Steven Michaud [:smichaud] (Retired)]

(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 62

[Josh Aas]

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.

Comment 63

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 64

[James Rome]

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.

Comment 65

[Josh Aas]

A patch for this is not likely to be in beta 8. We'll fix it as soon as we can.

Comment 66

[James Rome]

On the patched build, I am unable to open Minefield/preferences. Is this a side effect of this patch?

Comment 67

[Steven Michaud [:smichaud] (Retired)]

> 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*
:-)

Comment 68

[James Rome]

Preferences still work with 3.6, so I think my profile is OK.

Comment 69

[James Rome]

The problem is AdBlock Plus. If I disable that, preferences work again. But it does work with NoScript and Download StatusBar enabled.

Comment 70

[James Rome]

Oh, and it also stopped the add-ons manager window from appearing.

Comment 71

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix rev1 (restore missed calls to NPP_SetWindow())

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.

Comment 72

[Steven Michaud [:smichaud] (Retired)]

(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".

Comment 73

[Steven Michaud [:smichaud] (Retired)]

Here's a tryserver build made with my patch from comment #71:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-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.

Comment 74

[James Rome]

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.

Comment 75

[Steven Michaud [:smichaud] (Retired)]

> 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)?

Comment 76

[Ryan]

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.

Comment 77

[James Rome]

Yup. AdBlock Updater kills preferences in the unpatched Minefield, so this patch is ready to go as far as I am concerned.

Comment 78

[Benjamin Smedberg]

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.

Comment 79

[Steven Michaud [:smichaud] (Retired)]

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

Comment 80

[James Rome]

so please let us know when the nightlies have this in them, and if beta 8 will.

Comment 81

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110107 Firefox/4.0b9pre