This is Turkey's one of the major bank's internet site. There upper right corner you will see a "internet" link. click there. a window will pop for interactive banking. In this page it is suppose to load a java applet for login screen. But mozilla just stops and doesnt load anything. Normally after a time a meggage dialog has to appear and telling "ok tusuna bastiktan sonra devam edebilirsiniz.." . Process continues while entering customer number and cliking "giris" button. Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2+) Gecko/20010729

Over to Plug-ins.

OJI

Yes, I see this. It does not load.

with Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010805 This page has a different behavior. First process became very very slow and mozilla doesnt load the applet, or all page. Any ides?

SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)

Putting on 0.9.4 radar

We see that the last thing the applet does is: 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://www.isbank.com.tr/isbank.zip Connecting https://www.isbank.com.tr/isbank.zip

It appears we have a deadlock: Thread A: Java Plugin --------- USER32! 77e720c1() CJavaConsole::CreateAppWindow(void * 0x00921604) line 342 + 15 bytes KERNEL32! 77f04f3e() CJavaConsole::CreateAppWindow() MSG msg; while(GetMessage(&msg, NULL, 0, 0)) { DispatchMessage(&msg); } Thread B: Mozilla --------- _PR_MD_PR_POLL(PRPollDesc * 0x010d5d00, int 1, unsigned int 2610055) line 224 + 35 bytes PR_Poll(PRPollDesc * 0x010d5d00, int 1, unsigned int 2610055) line 115 + 17 bytes nsSocketTransportService::Run(nsSocketTransportService * const 0x010d5ec4) line 411 + 24 bytes nsThread::Main(void * 0x010d5920) line 105 + 26 bytes _PR_NativeRunThread(void * 0x010d5700) line 399 + 13 bytes _threadstartex(void * 0x010d5550) line 212 + 13 bytes KERNEL32! Thread C: Mozilla --------- NTDLL! 77f6825b() KERNEL32! 77f04f97() _PR_WaitCondVar(PRThread * 0x00a36eb0, PRCondVar * 0x00a35210, PRLock * 0x00a352c0, unsigned int 4474380) line 185 + 23 bytes PR_WaitCondVar(PRCondVar * 0x00a35210, unsigned int 4474380) line 532 + 23 bytes MemoryFlusher::Run(MemoryFlusher * const 0x00a35370) line 153 + 20 bytes nsThread::Main(void * 0x00a351c0) line 105 + 26 bytes _PR_NativeRunThread(void * 0x00a36eb0) line 399 + 13 bytes _threadstartex(void * 0x00a36d60) line 212 + 13 bytes KERNE Thread D: Java Plugin --------- CJavaPlugin::GetJavaObject(CJavaPlugin * const 0x1a429040, _jobject * * 0x0012d5c0) line 725 + 5 bytes nsHTMLAppletElementSH::GetPluginJSObject(JSContext * 0x04b9f100, JSObject * 0x03fbb8d8, nsIPluginInstance * 0x1a429028, JSObject * * 0x0012d630, JSObject * * 0x0012d624) line 4267 + 27 bytes nsHTMLExternalObjSH::PostCreate(nsHTMLExternalObjSH * const 0x1cb037f0, nsIXPConnectWrappedNative * 0x1cb049f0, JSContext * 0x04b9f100, JSObject * 0x03fbb8d8) line 3992 + 36 bytes XPCWrappedNative::GetNewOrUsed(XPCCallContext & {...}, nsISupports * 0x1c8b2d28, XPCWrappedNativeScope * 0x04bab150, XPCNativeInterface * 0x025fb0d0, XPCWrappedNative * * 0x0012d7b0) line 404 XPCConvert::NativeInterface2JSObject(XPCCallContext & {...}, nsIXPConnectJSObjectHolder * * 0x0012d8b4, nsISupports * 0x1c8b2d28, const nsID * 0x0283f090 iid, JSObject * 0x03ef65e0, unsigned int * 0x0012d86c) line 795 + 30 bytes nsXPConnect::WrapNative(nsXPConnect * const 0x010f63e0, JSContext * 0x04b9f100, JSObject * 0x03ef65e0, nsISupports * 0x1c8b2d28, const nsID & {...}, nsIXPConnectJSObjectHolder * * 0x0012d8b4) line 496 + 29 bytes nsDOMClassInfo::WrapNative(JSContext * 0x04b9f100, JSObject * 0x03ef65e0, nsISupports * 0x1c8b2d28, const nsID & {...}, long * 0x0012e588) line 747 + 58 bytes nsHTMLDocumentSH::GetProperty(nsHTMLDocumentSH * const 0x03086700, nsIXPConnectWrappedNative * 0x1c8b7d60, JSContext * 0x04b9f100, JSObject * 0x03ef6cb8, long 66022396, long * 0x0012e588, int * 0x0012d918) line 3671 + 42 bytes XPC_WN_Helper_GetProperty(JSContext * 0x04b9f100, JSObject * 0x03ef6cb8, long 66022396, long * 0x0012e588) line 780 + 47 bytes js_GetProperty(JSContext * 0x04b9f100, JSObject * 0x03ef6cb8, long 478894640, long * 0x0012e588) line 2416 + 149 bytes js_Interpret(JSContext * 0x04b9f100, long * 0x0012e740) line 2533 + 1998 bytes js_Invoke(JSContext * 0x04b9f100, unsigned int 1, unsigned int 2) line 824 + 13 bytes js_InternalInvoke(JSContext * 0x04b9f100, JSObject * 0x03ef65e0, long 66022160, unsigned int 0, unsigned int 1, long * 0x0012e920, long * 0x0012e868) line 896 + 20 bytes JS_CallFunctionValue(JSContext * 0x04b9f100, JSObject * 0x03ef65e0, long 66022160, unsigned int 1, long * 0x0012e920, long * 0x0012e868) line 3349 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x04b9ebd0, void * 0x03ef65e0, void * 0x03ef6b10, unsigned int 1, void * 0x0012e920, int * 0x0012e91c, int 0) line 946 + 33 bytes nsJSEventListener::HandleEvent(nsJSEventListener * const 0x03982890, nsIDOMEvent * 0x1caef9b4) line 139 + 74 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03986300, nsIDOMEvent * 0x1caef9b4, nsIDOMEventTarget * 0x04b9ff10, unsigned int 1, unsigned int 7) line 1196 + 20 bytes nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x1c807550, nsIPresContext * 0x1c844120, nsEvent * 0x0012f030, nsIDOMEvent * * 0x0012efe8, nsIDOMEventTarget * 0x04b9ff10, unsigned int 7, nsEventStatus * 0x0012f058) line 1869 + 36 bytes GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x04b9ff00, nsIPresContext * 0x1c844120, nsEvent * 0x0012f030, nsIDOMEvent * * 0x0012efe8, unsigned int 1, nsEventStatus * 0x0012f058) line 598 DocumentViewerImpl::LoadComplete(DocumentViewerImpl * const 0x1c818590, unsigned int 0) line 1084 + 47 bytes nsDocShell::EndPageLoad(nsIWebProgress * 0x03cf4924, nsIChannel * 0x03ce79f0, unsigned int 0) line 3726 nsWebShell::EndPageLoad(nsIWebProgress * 0x03cf4924, nsIChannel * 0x03ce79f0, unsigned int 0) line 893 nsDocShell::OnStateChange(nsDocShell * const 0x03cf4eb4, nsIWebProgress * 0x03cf4924, nsIRequest * 0x03ce79f0, int 131088, unsigned int 0) line 3647 nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x03cf4924, nsIRequest * 0x03ce79f0, int 131088, unsigned int 0) line 1095 nsDocLoaderImpl::doStopDocumentLoad(nsIRequest * 0x03ce79f0, unsigned int 0) line 734 nsDocLoaderImpl::DocLoaderIsEmpty() line 632 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x03cf4914, nsIRequest * 0x1c8c1c40, nsISupports * 0x1c844120, unsigned int 0) line 563 nsLoadGroup::RemoveRequest(nsLoadGroup * const 0x03c98dd0, nsIRequest * 0x1c8c1c40, nsISupports * 0x1c844120, unsigned int 0) line 512 + 44 bytes imgRequestProxy::OnStopRequest(imgRequestProxy * const 0x1c8c1c48, nsIRequest * 0x1c8bd120, nsISupports * 0x00000000, unsigned int 0) line 389 imgRequest::OnStopRequest(imgRequest * const 0x1c8bd248, nsIRequest * 0x1c8bd120, nsISupports * 0x00000000, unsigned int 0) line 637 ProxyListener::OnStopRequest(ProxyListener * const 0x1c8bd200, nsIRequest * 0x1c8bd120, nsISupports * 0x00000000, unsigned int 0) line 391 nsStreamListenerTee::OnStopRequest(nsStreamListenerTee * const 0x1caefeb0, nsIRequest * 0x1c8bd120, nsISupports * 0x00000000, unsigned int 0) line 25 nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x1c8bd124, nsIRequest * 0x1c8bff70, nsISupports * 0x00000000, unsigned int 0) line 2147 nsOnStopRequestEvent::HandleEvent() line 161 nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x1ca638c4) line 64 PL_HandleEvent(PLEvent * 0x1ca638c4) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x0103a900) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x003004ae, unsigned int 49462, unsigned int 0, long 17017088) line 1071 + 9 bytes USER32! 77e71268() 0103a900() Thread E: Mozilla --------- USER32! 77e720c1() nsDNSService::Run(nsDNSService * const 0x010d6b74) line 1293 + 21 bytes nsThread::Main(void * 0x010d69c0) line 105 + 26 bytes _PR_NativeRunThread(void * 0x010d67a0) line 399 + 13 bytes _threadstartex(void * 0x010d65f0) line 212 + 13 bytes KERNEL32! 77f04f3e() Thread F: Java Plugin --------- NTDLL! 77f6824c() USER32! 77e79150() USER32! 77e7919c() ATL::AtlWaitWithMessageLoop(void * 0x00000694) line 5421 CHttpsStreamListener::WaitEvent(CHttpsStreamListener * const 0x0096cac0) line 283 CJavaPlugin::GetHttpsForURL(CJavaPlugin * const 0x1a429028, const char * 0x0096cb10, char * * 0x1d17f330, int * 0x1d17f324) line 1157 CJavaPluginApp::GetHttpsURL(CJavaPluginApp * const 0x00000001, const char * 0x0096cb10, char * * 0x1d17f330, int * 0x1d17f324) line 413 getHttpsURL(const char * 0x0096cb10, char * * 0x1d17f330, int * 0x1d17f324) line 933 Java_sun_plugin_protocol_https_BrowserHttpsInputStream_openStream(JNIEnv_ * 0x0096b1a4, _jobject * 0x1d17f384) line 1295 + 14 bytes 04ef0d88() 04eee85a() 04eee85a() 04eee8aa() 04eee8aa() 04eee8aa() 04eee8aa() 04eee85a() 04eee8aa() 04eee8aa() 04eee85a() JVM! 6d4db40c() JVM! 6d4403ca() JVM! 6d4692fd() JVM! 6d4402de() JAVA! 6d251047() 04eee8aa() 04eee8aa() 04eee8aa() 04eee8aa() JVM! 6d4db40c() JVM! 6d4403ca() JVM! 6d4692fd() JVM! 6d4402de() JAVA! 6d251061() 04eee8aa() 04eee8aa() 04eee8aa() 04eee8aa() 04eee8aa() 04eee8aa() 04eee8aa() 04eee8aa() 04eee8aa() 04eee8aa() 04eee85a() 04eee922() JVM! 6d4db40c() JVM! 6d4403ca() JVM! 6d4692fd() JVM! 6d4402de() JVM! 6d44005c() JVM! 6d44f480() JVM! 6d482bf9() JVM! 6d482bc9() MSVCRT! 7800265a() KERNEL3

I've asked Rick Potts and Jud Valeski to see if this thread deadlock is similar to the one in bug 64332.

hey ed, you always come up with the *best* deadlocks!! it's alot harder to tell what's going on with this stack trace... it looks like the contention is between threads D & F. Thread D looks like the main mozilla UI thread. It is in the process of firing the onLoad() event for the page. It looks like some javascript in the onLoad() handler is accessing a property on the plugin... This ultimately causes a call to CJavaPlugin::GetJavaObject(...) which blocks :-( Thread F seems to be in a sub-event-loop as part of the call to CJavaPlugin::GetHttpsForURL(...). My bet is that thread F is holding on to the lock needed by CJavaPlugin::GetJavaObject(...). Since the call to GetJavaObject(...) is done on the UI thread, the whole UI blocks... I bet that if thread F ever left the sub-event-loop the UI would come back alive... but it doesn't look like that is happening :-( What is CJavaPlugin::GetHttpsForURL(...) doing? is it waiting for some event from the UI thread? -- rick

Reversing database corruption caused by bug 95857 and bug 95798. Pay no attention to the man behind the curtain.

I have mailed Stanley about this. No reply as yet.

Tested with JRE1.4 is OK to run the applet.

Do we understand what changed in JRE1.4 to make this work?

Rick, for one thing, there were several Java Plugin Side Liveconnect fixes.

Pushing back to 0.9.5 since this appears to be dependent on JDK1.4.

Ressign to Joe Chou, as I am no longer working officially on OJI.

Re-assign to sep.

with [Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5+) Gecko/20011110], problem page hangs, and if you try to close the window, it crashes mozilla with a runtime error. can we make this critical?

Ahmet: Which version of java plugin do you have? Did you you try jdk1.4beta3?

it looks like my question still hasn't been answered... "What is CJavaPlugin::GetHttpsForURL(...) doing? is it waiting for some event from the UI thread?" it appears that thread F is holding a lock which is causing everything to hang. -- rick

Igor, i have 1.3.01 i presume, i have not tried 1.4 yet.

I tried jdk1.4 and if i go directly to https://www.isbank.com.tr/secure/ssl_frame.htm then it works fine. However, if i click on label as suggested mozilla freeze.

I found another page (now Dutch) where a JAVA applet does not show. * installed win-32 binary of Mozilla 0.9.7+ (21 dec) on my win98 PC. * went www.utrecht.nl, saw i missed a plugin (* maybe the plugin just sucks: after the first installs i looked at http://www.mozilla.org/quality/browser/debugtc/bft_browser_applet.html: Mozilla shows the jigsaw and tries to get the same plugin - i did not even try) * confirmed installation of a java plugin from netscape.com * after the 1st install of the plugin Mozilla crashed on the page * after 2nd install of plugin Mozilla did not crash * plugin just simply does not show. - i notice a reload even does not show any images on the page and the word 'leeg' (Dutch for 'empty') right below where the java applet should show The java applet does show up in Netscape 6.2 (Mozilla/5.0 (Windows; U; Win98; en-GB; rv:0.9.4) Gecko/20011019 Netscape6/6.2 ) and IE 6.0

tried with nightly (i believe 26 feb 2002 Win98) with JRE 1.4 release candidate, page hangs mozilla and does not load the page. please do stg, this is the biggest bank over here. can this bug be "critical" ?

works for me 20020304 with JRE v1.4.0

Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020313, Java 1.4.0 (release) Page hangs! it does not work for me.

as commented above, i reopened this bug. Sorry for bugging, but i believe this page is crucial for mozilla's success in Turkiye.

Can someone please answer my question in comment #11 (and comment #22)? The key to fixing this deadlock is understanding what CJavaPlugin::GetHttpsForURL(...) is doing? -- rick

I have observed a similar problem, using builds 2002082606 and 2002082611. The first has Mozilla installed on an XP system in the default directory on the C:drive. The second on a Win 98 SE system in the default directory, but on the E: drive. Both show all Java plugins installed, and I also installed the latest 1.4.1 from Sun, which seemed to install okay in the plugins directory on the E: drive of the second system. The first loads Java applets okay from all sites I have tried. The second won't load any Java applets from any site. Does choice of installation drive affect the operation of Java in Mozilla?

i do not see this problem any more. i am using Win 2000 with java 1.4

I'm using, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 /usr/java/j2re1.4.1_02/plugin/i386/ns610/libjavaplugin_oji.so and trying APC Powerchute Network Shutdown Java Applet on a Network Management Card (AP9617) for Smart UPS (SM2200RM3U). The login prompt loads fine, when I type in everything and click OK. Nothing happens. I need to do a reload of the applet then retype everything, click OK to get in. This 100% reproducible.

Re-resolving as WFM per reporter's comment 32