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

RESOLVED FIXED

Status

Core Graveyard
Java: Live Connect
--
critical
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: ReleaseEngineer, Assigned: jst)

Tracking

({relnote, verified1.9.1.1})

unspecified
x86
Windows Vista
relnote, verified1.9.1.1
Bug Flags:
blocking1.9.1 -
blocking1.9.1.1 +
wanted1.9.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
It was working fine on Firefox 3.1 beta 2
(Reporter)

Updated

8 years ago
(Reporter)

Updated

8 years ago
Summary: Firefox 3.1 beta 3 does not have java-to-javascript live connect working with old Java plugin → [REGRESSION] java-to-javascript live connect is broken with old Java plugin on Firefox 3.1 beta 3
(Reporter)

Updated

8 years ago
Flags: blocking-firefox3.5?
Component: General → Java: Live Connect
Flags: blocking-firefox3.5?
Product: Firefox → Core
QA Contact: general → live-connect
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.
Flags: blocking1.9.2?
(Reporter)

Comment 3

8 years ago
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

8 years ago
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

8 years ago
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
(Reporter)

Comment 6

8 years ago
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.
(Reporter)

Updated

8 years ago
Severity: major → critical

Comment 7

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

Comment 8

8 years ago
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.
(Assignee)

Comment 9

8 years ago
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...
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 10

8 years ago
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.
jst: what's your feeling about fixing this in 3.5.1 vs. stop-ship?
Flags: wanted1.9.1.x?
Flags: blocking1.9.1?
Keywords: relnote
(Assignee)

Comment 12

8 years ago
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...
(Assignee)

Comment 13

8 years ago
Created attachment 385014 [details] [diff] [review]
Revert the IID change to nsIPluginInstancePeer2 and add nsIPluginInstancePeer2_1_9_1_BRANCH instead.
Assignee: nobody → jst
Status: NEW → ASSIGNED
Attachment #385014 - Flags: superreview?(mrbkap)
Attachment #385014 - Flags: review?(mrbkap)

Updated

8 years ago
Attachment #385014 - Flags: superreview?(mrbkap)
Attachment #385014 - Flags: superreview+
Attachment #385014 - Flags: review?(mrbkap)
Attachment #385014 - Flags: review+
(Assignee)

Comment 14

8 years ago
(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?
jst: agreed; let's get this done for 3.5.1, and have the fix in on trunk
Flags: wanted1.9.1.x?
Flags: wanted1.9.1.x+
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Whiteboard: [3.5.1?]

Comment 16

8 years ago
(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
(Assignee)

Comment 17

8 years ago
Created attachment 385236 [details] [diff] [review]
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).
Attachment #385236 - Flags: superreview+
Attachment #385236 - Flags: review+
(Assignee)

Comment 18

8 years ago
Created attachment 385287 [details] [diff] [review]
Updated trunk version, missed one spot...
Attachment #385236 - Attachment is obsolete: true
Attachment #385287 - Flags: superreview+
Attachment #385287 - Flags: review+
(Assignee)

Updated

8 years ago
Attachment #385287 - Attachment is patch: true
Attachment #385287 - Attachment mime type: application/octet-stream → text/plain

Updated

8 years ago
Duplicate of this bug: 483237
(Assignee)

Comment 20

8 years ago
Fix checked in on trunk.

http://hg.mozilla.org/mozilla-central/rev/0f97932be663
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Flags: blocking1.9.1.1?
Resolution: --- → FIXED
(Reporter)

Comment 21

8 years ago
Please reconsider this for 3.5.0
(Assignee)

Comment 22

8 years ago
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.
Whiteboard: [3.5.1?]
(Assignee)

Updated

8 years ago
Duplicate of this bug: 501855
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 ?
(Assignee)

Comment 25

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

Comment 26

8 years ago
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.
(Assignee)

Comment 27

8 years ago
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?
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?).
Flags: blocking1.9.1.1? → blocking1.9.1.1+
(Assignee)

Updated

8 years ago
Attachment #385014 - Flags: approval1.9.1.1?
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
Attachment #385014 - Flags: approval1.9.1.1? → approval1.9.1.1+
Please land immediately.
(Assignee)

Comment 31

8 years ago
Created attachment 388576 [details] [diff] [review]
Updated branch diff that landed.
(Assignee)

Comment 32

8 years ago
Fixed for 1.9.1.1.

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9d3a32d9ef1e
Keywords: fixed1.9.1.1
(Assignee)

Comment 33

8 years ago
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...
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
Keywords: fixed1.9.1.1 → verified1.9.1.1

Updated

8 years ago
Duplicate of this bug: 501453

Updated

7 years ago
Component: Java: Live Connect → Java: Live Connect
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.