82977 - Java applet at hushmail causes Java to lock up

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect, P1)

Description

[Brian Haskin (Janzert)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9+) Gecko/20010526
BuildID:    20001052608

When attempting to use hushmail the first time the java applet simply appears to
never load all the way. If you then go back and try a second time the Java
console will stop responding and any new applets fail to load.

Reproducible: Always
Steps to Reproduce:
1. Go to www.hushmail.com
2. Either try to log into an existing account or create a new account.
   To start a new account:
     a. click on "sign up for free"
     b. scroll to the bottom and click on continue
     c. click on continue for option 2
3. The applet will fail to load all the way, then hit the back button and return
to the applet page.

Actual Results:  The java console will stop responding and no new applets will load.

Expected Results:  The hushmail applet should come up.

Here is the output from the java console with a trace level of 5

When loading the applet for the first time:
Registered modality listener
Referencing classloader: sun.plugin.ClassLoaderInfo@64c34e, refcount=1
Added trace listener:
sun.plugin.navig.win32.AppletPluginPanel[com.hushmail.client.gui.newaccount.NewAccountApplet,0,0,720x385,invalid,layout=java.awt.BorderLayout]
Sending events to applet. LOAD
Sending events to applet. INIT
Sending events to applet. START
Determine if the applet requests to install any HTML page
HTML Installation finished.
Determine if the applet requests to install any JAR
Jar cache option: null
Jar archive(s): null
Jar cache version(s): null
Applet Installation finished.
Opening https://user8.hushmail.com/java/1.401/NewAccountApplet.jar
Connecting https://user8.hushmail.com/java/1.401/NewAccountApplet.jar

Then after hitting the back button:
Sending events to applet. STOP
Unregistered modality listener
Removed trace listener:
sun.plugin.navig.win32.AppletPluginPanel[com.hushmail.client.gui.newaccount.NewAccountApplet,0,0,720x385,invalid,layout=java.awt.BorderLayout]
Applet loading in progress, stop loading.
Sending events to applet. STOP
Sending events to applet. DESTROY
Sending events to applet. DISPOSE
Sending events to applet. QUIT

Then going back to the applet page:
Registered modality listener
Referencing classloader: sun.plugin.ClassLoaderInfo@64c34e, refcount=2

At this point the java console has stopped responding and will even fail to repaint.

Closing all mozilla windows will leave the java console and java icon in the
taskbar. The only way to close these is to hit ctr-alt-del and end the 'Java
Console' or 'Mozilla' task.

One other note, it seems from bug 63174 that this applet was working at one
time. Should this be marked as a regression?

Comment 1

[Phil Schwartau]

*** Bug 83077 has been marked as a duplicate of this bug. ***

Comment 2

[edburns]

I see this.  accept.

Comment 3

[edburns]

I'm finding that nsPluginHostImpl::GetURL() is being called, as expected.  The 
plugin stream listener is called with onDataAvailable, but the length is 0.  
Nothing happens after this point.

Comment 4

[edburns]

This is interesting.  

nsPluginHostImpl::OnDataAvailable() calls the plugin's stream listener like 
this:

   rv =  mPStreamListener->OnDataAvailable((nsIPluginStreamInfo*)
mPluginStreamInfo, 
                                            aIStream, 
                                            absoluteOffset+amtForwardToPlugin, 
                                            aLength);


However, the implementation in the plugin is defined like this:

NS_METHOD CHttpsStreamListener::OnDataAvailable(nsIPluginStreamInfo* 
pluginInfo, 
                                                nsIInputStream* input,
                                                PRUint32 length)
{

Unfortunately, the length seen by the plugin is 0.

Comment 5

[Oliver Klee]

Nominating for 0.9.1. This broke online banking for me.

Comment 6

[edburns]

This bug was introduced when DougT modified nsPluginHostImpl.cpp from version 
1.254 to 1.255.  Re-assigning to dougt.  Doug, I thought you rolled this change 
back?

Comment 7

[edburns]

add me for CC.

Comment 8

[Doug Turner (:dougt)]

peterl may have not checked the rollback in.  cc-ing him

Comment 9

[Peter Lubczynski]

Yup, my changes from bug 82415 aren't in yet. Waiting for [e-mail] 
approval. 

Comment 10

[Doug Turner (:dougt)]

peter, please marked fixed when you check your changes in.

Comment 11

[edburns]

Peter hasn't checked in the rollback yet.

On 30 May 14:56:52, Peter Lubczynski wrote:
> I'm waiting for [e-mail] approval.
> 

Comment 12

[drapeau]

Typo in status whiteboard: now correct.

Comment 13

[Peter Lubczynski]

The patch to bug 82415 is now checked in. This should be FIXED with tomorrow's 
build. Please re-open if not.

Comment 14

[shrirang khanzode]

qa->pmac

Comment 15

[Patty Mac]

This still not fixed yet on windows 98 and linux redhat 6.2 (branch build:
2001-10-09-10-0.9.4). The applet fail to load it. But on netsape 4.x,
the hushmail applet loads fine. Screenshot will attach.

Comment 16

[Brian Haskin (Janzert)]

This should probably be opened up in a new bug. This was fixed at the end of
May. Sometime in August hushmail started using a new applet that doesn't work
with Mozilla. But the behaviour seems to be quite a bit different than what it
was with this bug.

Comment 17

[Peter Lubczynski]

The applet laods fine, there are no lockup. This bug is FIXED.

Please open new bugs on other issues.

Comment 18

[Patty Mac]

Based on the additional comment #16, this bug is fixed. Currently, the behavior
is quite different than the original of this bug. Therefore, this bug should
close (commercial build: 2002-02-06-06-trunk) with jre 1.3.1

Here is the error in the java console window:

java.lang.ClassFormatError: com/hush/core/security/applet/HushEncryptionEngine
(Bad magic number)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadCode(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)