288356 - Java applet + screen reader: heap corruption brings down Firefox

Status: RESOLVED FIXED

(Core Graveyard :: Java: OJI, defect)

Description

[Aaron Leventhal]

Steps:
1. Run Window-Eyes screen reader (demo at www.gwmicro.com)
2. Launch Firefox and load a page with an applet such as
www.wainhouse.com or www.iandury.co.uk
3. Watch Firefox window close or hang. I don't get a crash report dialog.
Or, run in debugger and get a "user exception" which means heap corruption. The
stack trace is always different and starts out in java.dll

Other data points:
- When I ran in IE I did not get the problem, but perhaps it was running the MS
JRE at that point?
- The crash went away when I uninstalled both MS and Sun JRE's and installed JRE
1.4.2 from IBM employee website. So, it does relate to what JRE is running.
- The crash still occured when I disabled Mozilla's screen reader support code
that exposes MSAA
- At least one other person experienced the same crash and has seen it using
Sun's JRE in IE

Comment 1

[Aaron Leventhal]

I don't have any access to the internals of the JRE, so this is a really tough
problem to diagnose.

If no one steps forward to help my plan is to put on a temporary band aid for
Firefox 1.1. I will default the pref "security.enable_java" to false when a
Windows screen reader is present. This is acceptable because the only Windows
screen reader that will support Firefox 1.1 doesn't support Java yet.

Comment 2

[Aaron Leventhal]

Attachment: Default Java support to off when Windows screen reader is running. Java support can still be turned back on in Tools->Options->Content->Enable Java

I think the problem might be in the newer Sun JRE's. I'll see if I can get more
info.

Any thoughts from other bugzilla users would be welcome.

Comment 3

[Kyle Yuan]

Comment on attachment 179104 [details] [diff] [review]
Default Java support to off when Windows screen reader is running. Java support can still be turned back on in Tools->Options->Content->Enable Java

this is acceptable, but I'd prefer to put a //XXX comment that says this is
only a temporary work around to this issue.

>+      if (!isJavaEnabledByUser) {
>+        // Java is enabled by default, not explicitly by the user
>+        PRBool isScreenReaderActive = 257;
assigning 257 to a bool variable does not look good to me.

Comment 4

[Aaron Leventhal]

Comment on attachment 179104 [details] [diff] [review]
Default Java support to off when Windows screen reader is running. Java support can still be turned back on in Tools->Options->Content->Enable Java

Will add // XXX This is a temporary workaround until issues are sorted out

Comment 5

[Aaron Leventhal]

Oh, thanks for noticing the 257 assignment -- that was for debugging something.
I'll remove the initial assignment.

Comment 6

[Aaron Leventhal]

More data points:

Sun build 1.5.0_02-b09 exhibits the heap corruption:
1) in IE: not in any apparent way
2) in Firefox when run in debugger: 
     a) with JAWS: yes
     b) with Window-Eyes: yes

IBM build build 1.4.2
Does not exhibit problem

Comment 7

[Johnny Stenback (:jst)]

Comment on attachment 179104 [details] [diff] [review]
Default Java support to off when Windows screen reader is running. Java support can still be turned back on in Tools->Options->Content->Enable Java

Yeah, add the comments that Kyle mentioned. sr=jst

Comment 8

[Aaron Leventhal]

Checking in accessible/src/msaa/nsAccessNodeWrap.cpp;
/cvsroot/mozilla/accessible/src/msaa/nsAccessNodeWrap.cpp,v  <-- 
nsAccessNodeWrap.cpp
new revision: 1.15; previous revision: 1.14
done