Closed Bug 492251 Opened 15 years ago Closed 15 years ago

Spurious SyntheticEvent Objective-C exception, which causes a crash

Categories

(Plugins Graveyard :: Java (Java Embedding Plugin), defect)

Product:
Plugins Graveyard
Component:
Java (Java Embedding Plugin)
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: christoffer.valstad, Assigned: smichaud)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

when accessing the site (www.skandiabanken.no) and logging in, FF crashes so I cant log in at all. 

the crash happens only when Im logging in. browsing the site is fine.

This looks to be related to the login option: BANKID. This is a common log in solution found in many Norwegian banks. 

Reproducible: Always

Steps to Reproduce:
1. I enter my username
2. click next, firefox is still ok. 
3. the screen refreshes to give me further instructions for logging in. in this screen FF crashes when Im selecting an option in a drop down menu. It does happen that FF will let me choose the menu item, but FF will then crash when Im pressing next in this screen. 
Actual Results:  
ff crashed. 

Expected Results:  
logged me in successfully. 

happens with another bank Im using also that uses the same log in solution (BankID).

https://nettbank.edb.com/Logon/index.jsp?domain=1802&from_page=http://www.sparebanken-hedmark.no&to_page=https://nettbank.edb.com/payment/transigo/logon/done&seg=private
stacktrace: 0c5a655e-7a5e-4cce-857f-2f30f2090510
bp-0c5a655e-7a5e-4cce-857f-2f30f2090510

0  	XUL  	nsObjCExceptionLogAbort  	nsObjCExceptions.h:152
1 	XUL 	-[ChildView processKeyDownEvent:keyEquiv:] 	widget/src/cocoa/nsChildView.mm:5737
2 	XUL 	-[ChildView performKeyEquivalent:] 	widget/src/cocoa/nsChildView.mm:6032
3 	AppKit 	AppKit@0x1bf7f5 	
4 	AppKit 	AppKit@0x1bf7f5 	
5 	AppKit 	AppKit@0x1bf55e 	
6 	XUL 	-[ToolbarWindow performKeyEquivalent:] 	widget/src/cocoa/nsCocoaWindow.mm:1916
7 	AppKit 	AppKit@0x320e6d 	
8 	Foundation 	Foundation@0xb3e2 	
9 	CoreFoundation 	CoreFoundation@0x735f4 	
10 	CoreFoundation 	CoreFoundation@0x73cd7 	
11 	HIToolbox 	HIToolbox@0x302bf 	
12 	HIToolbox 	HIToolbox@0x30011 	
13 	HIToolbox 	HIToolbox@0x2ff4c 	
14 	AppKit 	AppKit@0x40d7c 	
15 	AppKit 	AppKit@0x4062f 	
16 	JavaEmbeddingPlugin 	JavaEmbeddingPlugin@0x12fc2 	
17 	XUL 	nsAppShell::ProcessNextNativeEvent 	widget/src/cocoa/nsAppShell.mm:626
18 	XUL 	nsBaseAppShell::DoProcessNextNativeEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:151
19 	XUL 	nsBaseAppShell::OnProcessNextEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:278
20 	XUL 	nsAppShell::OnProcessNextEvent 	widget/src/cocoa/nsAppShell.mm:789
21 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:497
22 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:180
23 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/src/xpwidgets/nsBaseAppShell.cpp:121
24 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/src/cocoa/nsAppShell.mm:405
25 	CoreFoundation 	CoreFoundation@0x7363e 	
26 	CoreFoundation 	CoreFoundation@0x73cd7 	
27 	HIToolbox 	HIToolbox@0x302bf 	
28 	HIToolbox 	HIToolbox@0x300d8 	
29 	HIToolbox 	HIToolbox@0x2ff4c 	
30 	AppKit 	AppKit@0x40d7c 	
31 	AppKit 	AppKit@0x4062f 	
32 	JavaEmbeddingPlugin 	JavaEmbeddingPlugin@0x12fc2 	
.....

Looks like an OS X Exception related to the java plugin
Do you need to have an account at these banks to see the crash?

In other words, can you just make up a username and still see the crash?
Unfortunately no. I can attach screenshots if that helps?
> I can attach screenshots if that helps

It doesn't help people who (like myself) don't have accounts at those
banks.

There's not much that can be done about this bug until someone finds a
publicly accessible way to reproduce it.

I'm also not convinced it's a Java bug -- since the crash happens in
Cocoa widgets code, I think it's more likely to be a Cocoa widgets
bug.  But of course I can't really know until I can reproduce the
crash.

There is one thing you can do to help, though.  Try reproducing the
crash in Firefox 3.0.10, Firefox 2.0.0.20 and the latest releases of
Seamonkey (1.1.16) and Camino (1.6.7).  Let us know which ones you can
reproduce the crash in.

> User-Agent:   Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us)
> AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
> Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
> rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

Did you really change your Firefox 3.5b4 user agent string to be the
same as Safari's?  If so, try restoring the user agent string to its
default, and see if you can still reproduce the crashes.
>Did you really change your Firefox 3.5b4 user agent string to be the
>same as Safari's?  If so, try restoring the user agent string to its
>default, and see if you can still reproduce the crashes.

It looks more like the reporter used Safari to report the bug (the first UA string is pasted with JS by the bug filing form) and the second UA string is from a html form that zhe user must fill out.
I reported the bug from Safari, thats correct!

I tried Seamonkey 1.1.16, Camino 1.6.7, Firefox 2.0.0.20 and they all worked. 

Firefox 3.0.10 crashed just like 3.5.b4.
(In reply to comment #8)

Thanks!  This information is very helpful (though unfortunately it
doesn't clinch the problem).

Here's one more download to try -- Camino 2.0b2 (which like FF 3.0 and
FF 3.5 is based on 1.9.0 branch code,
ftp://ftp.mozilla.org/pub/mozilla.org/camino/releases/Camino-2.0b2.dmg).
Crashes at the same step in the log in with Camino 2. 

I have however found something interesting. 
I the second screen in the log in process I get a drop down menu and a field that needs to be filled out. If the second screen looks like this, the crash happens every time. 

At random intervals, the bank changes the log in procedure. The second screen will then contain two empty fields instead of a drop down and an empty field. If the second screen contains two empty fields, I can log in successfully.
I just looked at bp-0c5a655e-7a5e-4cce-857f-2f30f2090510 again, and
found the following under "Obj-C Exception data":

AWT error: Attempt to call non-applicable method "isARepeat" on SyntheticEvent!

Now I think I understand the problem, and may actually be able to fix
it (or rather work around it).

As best I can tell, this is ultimately an Apple bug (in Apple's Java
Virtual Machines):

For reasons that are unclear, Apple doesn't want certain methods
called on objects of class SyntheticEvent (an undocumented subclass of
NSEvent, used only in Apple's JVMs).  To catch these calls, Apple adds
methods to SyntheticEvent whose only purpose is to throw an error on
any call to the method.  One such is 'keyCode'.  But these calls are
still sometimes made from Apple's own code.

Recent versions of the JEP have a workaround for the errors you see
when [SyntheticEvent keyCode] is called.  But apparently I need to
extend the workaround to SyntheticEvent's 'isARepeat' method.  I'll do
that in my next release of the JEP.

However, there's also a sense in which this is a Cocoa widgets bug:

The "Attempt to call non-applicable method ..." exceptions are clearly
non-fatal.  But (as of the patch for bug 163260) all Objective-C
exceptions default to being fatal.

We've already added code to make several Objective-C exceptions
non-fatal (see bug 461381, bug 470864 and bug 442245).  Perhaps we
should try to do the same for this exception.
Assignee: nobody → smichaud
Component: General → Java Embedding Plugin
Product: Firefox → Core
QA Contact: general → java.jep
Summary: crashing when logging in → Spurious SyntheticEvent error, leading to a crash
Summary: Spurious SyntheticEvent error, leading to a crash → Spurious SyntheticEvent Objective-C exception, which causes a crash
(In reply to comment #10)

What do you mean by "second screen"?

Do you just mean "second page" or "second window" on the same screen?
Its the second window on the same screen. 

In the first window I enter my user-ID, in the second window Im prompted for the password key and the type of key Im using.
(In reply to comment #13)

Thanks for the info.

It's a bit academic for now (since ordinary users don't have the
access required to reproduce your STR).  But it might be useful in the
future (when/if we get more reports about this bug).
The same problem exist with Mac OS X 10.5.7. Anyways, what is the next step now? I doubt that many people will go through with the effort of reporting bugs like these. They will simply use Safari or Opera instead. Anything that can be done with this bug?
> Anything that can be done with this bug?

Only what I've already said.
I've just released version 0.9.7.1 of the Java Embedding Plugin, which
should fix this problem.

Please try it out, c val.

To do this you'll need to install JEP 0.9.7.1 "over" the older
versions currently bundled with Mozilla.org browsers.  I recommend
installing the new JEP to your /Library/Internet Plug-Ins/ folder,
then removing older copy(ies) of the JEP from your Mozilla.org
browser(s).  For more information see the JEP Readme
(http://javaplugin.sourceforge.net/Readme.html).

For more information see bug 493629.
It works fine now. Great work!
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Component: Java Embedding Plugin → Java (Java Embedding Plugin)
Product: Core → Plugins
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.