484744 - [REGRESSION] java-to-javascript live connect is broken with old Java plugin on Firefox 3.1 beta 3

Status: RESOLVED FIXED

(Core Graveyard :: Java: Live Connect, defect)

Description

[ReleaseEngineer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 (.NET CLR 3.5.30729)

Firefox 3.1 beta 3 does not have java-to-javascript live connect working with old Java plugin. Live connect works only with next generation plugin. For backward compatibility, the old plugin must be able to have java-to-javascript live connect capability in Firefox 3.1. We detected this wehn we turn off the next generation plug-in from Java control panel advanced tab. It was working in Firefox 3.1 beta 2. It may be a regression introduced in beta 3.

Reproducible: Always

Steps to Reproduce:
1. Turn off next generation plug-in from Java control panel advanced tab
2. A small applet which makes a java-to-javascript communication
3. Java console throws exception
Actual Results:  
Live connect does not work when done from java-to-javascript with old plugin.

Expected Results:  
Live connect should work when done from java-to-javascript with old plugin.

Comment 1

[ReleaseEngineer]

It was working fine on Firefox 3.1 beta 2

Comment 2

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

Is there a set of steps to reproduce with a published site or a testcase we can use to confirm this bug?

--> Core::Java:LiveConnect, carrying over blocking flag.

Comment 3

[ReleaseEngineer]

Actually I put a URL up there.

http://trephine.org/t/index.php?title=File_browser

The live connect applet on this site shows the problem clear.

Comment 4

[Pierre]

I am also experiencing this problem on Windows XP SP3 with an 1.5.0_16 JRE.

Examples:
(1) http://www.ch-werner.de/swishej/kwsearch.htm
(2) http://developer.apple.com/internet/safari/samples/ColorBlockApplet.html
NB: to test java to javascript communication, you need to download the above html file and the referenced ColorBlock.jar file on your computer. Then add mayscript="true" on the applet tag in the local html file.
Otherwise, you get a cryptic "null" error message in the java console.

Results:
(1) loads in Firefox 2.0.0.20, 3.0.8 & 3.1 Beta 2 but doesn't in 3.1 Beta 3
(2) java to javascript communication, by clicking the colored box, works in Firefox 2.0.0.20, 3.0.8 & 3.1 Beta 2 but doesn't in 3.1 Beta 3
javascript to java communication, by clicking one of the 3 "Paint the Box ..." buttons, works with the 4 above versions, though.

With an 1.6.0_13 JRE:
(1) loads in Firefox 3.1 Beta 3
(2) Java to JS communication works in Firefox 3.1 Beta 3, even without mayscript="true"

Comment 5

[dshah]

I think my problem is also related with this bug on firefox 3.1beta3.

I get the following exception from liveconnect when launching an applet:

The java console shows the following:

Java Plug-in 1.5.0_06
Using JRE version 1.5.0_06 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\dshah


----------------------------------------------------
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
p:   reload proxy configuration
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>
----------------------------------------------------

enable_logging not set, default to 1.
netscape.javascript.JSException
	at netscape.javascript.JSObject.getWindow(Unknown Source)
	at dsSetupAppletImpl.initLiveConnect(dsSetupAppletImpl.java:340)
	at dsSetupAppletImpl.initialize(dsSetupAppletImpl.java:63)
	at dsSetupApplet.init(dsSetupApplet.java:103)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
initLiveConnect: netscape.javascript.JSException
browser: false, document: false, cookies: false
netscape.javascript.JSException
	at netscape.javascript.JSObject.getWindow(Unknown Source)
	at dsSetupAppletImpl.initLiveConnect(dsSetupAppletImpl.java:340)
	at dsSetupAppletImpl.notifyAppletReady(dsSetupAppletImpl.java:358)
	at dsSetupApplet.init(dsSetupApplet.java:111)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
initLiveConnect: netscape.javascript.JSException
browser: false, document: false, cookies: false
java.lang.NullPointerException
	at dsSetupAppletImpl.notifyAppletReady(dsSetupAppletImpl.java:360)
	at dsSetupApplet.init(dsSetupApplet.java:111)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
notifyAppletReady: java.lang.NullPointerException
[init] setup applet initialized
[jshelper] Waiting for a js call

Comment 6

[ReleaseEngineer]

This bug looks still tagged unconfirmed. Is it going to be fixed in Firefox 3.5? I do not see Firefox 3.5 flag up there.

Comment 7

[dshah]

This problem is occuring even on the firefox 3.5b99 version...

Comment 8

[hao.dong]

This problem can occur in FF3.5 rc2 with OJI plugin of Sun JRE 1.6.0_16 (internal build) on windows. It does not occur with FF 3.0.11. It is a regression in 3.5.

The Linux OJI plugin works with both 3.0.11 and 3.5 rc2.

The new npruntime java plugin works fine in FF 3.5 rc2.

Comment 9

[Johnny Stenback (:jst)]

This broke on the 1.9.1 branch between builds from 2009-01-24-03 and 2009-01-25-03. The checkins in that range are at http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2009-01-24+03%3A00&enddate=2009-01-25+05%3A00 and none of those changes look related to what's going on here. The change likely happened a bit earlier than that range. I'm building right now to get an idea of what changeset caused this...

Comment 10

[hao.dong]

On java plugin side, the failure is to get the javascript execution thread.

It fails to get a pointer to nsIPluginInstancePeer2 interface.
QueryInterface(kIPluginInstancePeer2IID, (void**)&spPluginInstancePeer2) returns an error.

Comment 11

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

jst: what's your feeling about fixing this in 3.5.1 vs. stop-ship?

Comment 12

[Johnny Stenback (:jst)]

Given that this broke in January and it took almost two months for anyone to notice, I don't know that this needs to be a stop ship. I would think that this is a problem mostly in enterprise settings where there's a dependency on old Java versions etc, and in those settings they'd be unlikely to update to Firefox 3.5 right away as well, so taking this in 3.5.1 sounds reasonable as well.

The reason for the breakage is the interface IID change in the fix for bug 474866, and the fix is to revert that IID change and add a 1_9_1_BRANCH interface with the new method. I've got a fix that does that that I'll attach...

Comment 13

[Johnny Stenback (:jst)]

Attachment: Revert the IID change to nsIPluginInstancePeer2 and add nsIPluginInstancePeer2_1_9_1_BRANCH instead.

Comment 14

[Johnny Stenback (:jst)]

(In reply to comment #10)
> On java plugin side, the failure is to get the javascript execution thread.
> 
> It fails to get a pointer to nsIPluginInstancePeer2 interface.
> QueryInterface(kIPluginInstancePeer2IID, (void**)&spPluginInstancePeer2)
> returns an error.

Hao, thanks for digging in on your end here. Any idea why this isn't affecting the OJI based Java plugin on Linux?

Comment 15

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

jst: agreed; let's get this done for 3.5.1, and have the fix in on trunk

Comment 16

[hao.dong]

(In reply to comment #14)
> Any idea why this isn't affecting
> the OJI based Java plugin on Linux?

On Linux, it does not show this regression in FF 3.5. But java->javascript does not work at all with both FF 3.5 and 3.0.11. It uses nsILiveConnect interface to call GetWindow(). The returned result is zero. There is no exceptions thrown, just failed silently. This is probably broken since FF 3.0

Comment 17

[Johnny Stenback (:jst)]

Attachment: trunk version, same thing, different interface name and merged...

I'll land this on the trunk, but we'll only get limited use from landing this as the landscape on the trunk has changed quite a bit already wrt this interface, and in fact this interface is going away completely on the trunk soon as well (as part of Josh's XPCOM plugin support removal).

Comment 18

[Johnny Stenback (:jst)]

Attachment: Updated trunk version, missed one spot...

Comment 20

[Johnny Stenback (:jst)]

Fix checked in on trunk.

http://hg.mozilla.org/mozilla-central/rev/0f97932be663

Comment 21

[ReleaseEngineer]

Please reconsider this for 3.5.0

Comment 22

[Johnny Stenback (:jst)]

I'm afraid this was brought to our attention too late for 3.5.0 :( It should be included in the first update of 3.5 though.

Comment 24

[Jean-Marc Desperrier]

I think this needs to be checked in the branch *very soon* in order to be in 3.5.1

It has wanted1.9.1.x + and has baked on trunk.
Is there anything else required before the branch check-in can happen ?

Comment 25

[Johnny Stenback (:jst)]

I just need a blocking1.9.1.1+ in the bug and then it can land.

Comment 26

[Eric]

i just wanted to check in on this bug and see if it's going to make it into 3.5.1?  Unfortunately, I am not immediately able to decode what/how "blocking1.9.1.1+" means/do.  

Please forgive my ignorance.  Appreciate a response, this is a pretty significant issue for our product.  cheers.

Comment 27

[Johnny Stenback (:jst)]

The current plan, AFAIK, is to include this fix in Firefox 3.5.1. The only reason it hasn't been committed yet is that this bug needs to be approved, and that process hasn't started yet for Firefox 3.5.1 AFAIK.

Sam, can you approve this for 1.9.1.1, or are we delaying landing stuff there for some reason?

Comment 28

[Samuel Sidler (old account; do not CC)]

Johnny: Please request approval on the patch you want to land. I think just the first one, but I'm not sure (does it apply alright?).

Comment 29

[Samuel Sidler (old account; do not CC)]

Comment on attachment 385014 [details] [diff] [review]
Revert the IID change to nsIPluginInstancePeer2 and add nsIPluginInstancePeer2_1_9_1_BRANCH instead.

Approved for 1.9.1.1. a=ss

Comment 30

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

Please land immediately.

Comment 31

[Johnny Stenback (:jst)]

Attachment: Updated branch diff that landed.

Comment 32

[Johnny Stenback (:jst)]

Fixed for 1.9.1.1.

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9d3a32d9ef1e

Comment 33

[Johnny Stenback (:jst)]

For anyone who's looking at verifying this, the easiest way I found to reproduce this was to use the url http://www.ch-werner.de/swishej/kwsearch.htm (from comment 4), loading that page with the new java plugin disabled in Firefox 3.5 gives an error at the top of the page, with this fix included, the input box and buttons for the search on that page loads and functions. With the new java plugin there is no difference here...

Comment 34

[Tony Chung [:tchung]]

Thanks for the testcase jst.  Verified fix on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090715 Shiretoko/3.5.1pre
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090715 Shiretoko/3.5.1pre
and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1pre) Gecko/20090715 Shiretoko/3.5.1pre