318677 - Java Applets Locks User Scrolling, then Locks Keyboard, and then Crashes

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[rhedst1]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

I own a G4 Powerbook running Mac OS X 10.4 with all the latest patches installed. I was visiting some web pages when I noticed that sometimes I could not scroll unless I restarted Firefox. I decided to look further into the problem and I noticed that this was occurring when I Java applet was being loaded. For example, in the URL I provided there is a Java applet. I would load this applet and then go to a website where I would need to scroll. I can scroll by using the sidebar, but I am unable to scroll by using the two-finger drag option on my laptop. Sometimes, the keyboard would eventually lockup and I would be unable to type anything in the URL field or in any text form. Sometimes, Mozilla would crash.

I tried this on my Windows XP workstation and I could not repeat this. However, I can always repeat this on my laptop.

Reproducible: Always

Steps to Reproduce:
1. Visit the Provided URL to Load the Java Applet
2. Go to a Website that Requires Scrolling
3. Try scrolling using the trackpad with the two fingered scroll enabled

Actual Results:  
Scrolling does not work, keyboard sometimes locks up, and then Firefox sometimes crashes.

Expected Results:  
Firefox should allow me to scroll and it definitely should not crash after loading a Java Applet. End of story.

I'm not entirely new to testing applications, but I am unfamiliar with what is going on under the hood of Firefox. This seems like it is only isolated to a Mac, but I could be wrong. It might just be unnoticeable on a Windows machine. All I know is that a Java Applet is loading and it does not seem like it is closing properly. And because I gradually lose control of the application inputs and then it crashes, I think this is some type of memory issue, which warrents me to keep this confidential.

Comment 1

[Daniel Veditz [:dveditz]]

Josh, could you look at this Mac/Java issue and see if
 - you can reproduce it
 - if so, is the problem in Firefox or Java?

Comment 2

[Josh Aas]

Steven - ideas?

I cc'd steven on this bug because he is the author of JEP, the Java plugin we embed on Mac OS X.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Aside from the crashes, this seems to be a dup of bug 309344.

Why was this marked "security-sensitive"?  Just because of the crashes?  It's
only certain kinds of crashes that can have security issues.  For example,
crashes caused by dereferencing a NULL pointer aren't exploitable, but crashes
caused by a buffer overflow generally are exploitable.

Before I can say anything about the crashes, or even know where they're
happening, I need some crash logs.  In particular, I need crash logs produced
by OS X's crashreporterd (not Talkback crash logs).

Each time Firefox crashes, a new crash log is appended to the
firefox-bin.crash.log file in the Library/Logs/CrashReporter directory under
your home directory (i.e. to
~/Library/Logs/CrashReporter/firefox-bin.crash.log).

Each new log starts with a header that looks something like this:

> **********
>
> Host Name:      Swann
> Date/Time:      2005-05-02 17:38:33.741 -0500
> OS Version:     10.4 (Build 8A425)
> Report Version: 3

You should be able to tell by the timestamp which log(s) correspond to the
crash(es) you're reporting here.  If not, then follow the procedure you've
given in comment #0 to trigger two or three new crashes.

Then for each relevant crash log (but for no more than three of them):

1) Copy the log (all of it) to a separate file.
2) Use "Create a New Attachment" (above) to "attach" it to this bug report.

Thanks in advance!

Comment 4

[rhedst1]

Attachment: Specific Portion of Crash Log

Sorry about adding the bug as a security risk. Like I said, I do not have much experience with this, so I did not know exactly what to put. All I know is Java was causing the application to crash but only sometimes. I would lose scrolling and then possibly keyboard functionality. I thought it might be a memory issue, but I also know that memory issues are not necessary caused by buffer overflows. Anyway, if I find another bug, I'll be sure not to put security risk unless I have definite proof.

I attached a portion of the log file. It contains the specific log of the crash I was able to reproduce today. I can always repeat the scrolling problem, but it is more difficult to reproduce the keyboard lock and crashing. But if you can get the keyboard to lock, it will eventually crash. What I have found is that having a Java Applet open and then typing in a web form will produce this specific scenario faster.

Comment 5

[rhedst1]

Attachment: Second log file of reproducable crash

I can now reproduce the crash. Here is a list of instructions:

1) Go the the link I listed in the original bug report. This will load a Java Applet.
2) Go to the following website: www.java.com/en/games/desktop/sudoku.jsp.
3) Click TRY IT NOW! and either Accept or Cancel
4) Finally Click on the Search Text Box at the Top Right Corner of the Page and try typing something. Your computer should be unable to type anything.
5) If you try to click inside Firefox's URL bar or if you try to hotkey to it, Firefox will crash.

I attached another log file.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Thanks for your crash reports.  I have an inkling what the problem is, and how
to fix it.

But I'm puzzled by the instructions you've given in comment #5.  When I
followed them, I didn't end up loading a Java applet at all.  Instead I was
asked if I wanted to download and run a "Java Web Start" file.  When I said OK
to this, the file was downloaded to my desktop and run outside the browser
(i.e. in a separate process).  I didn't have problems of any sort -- crashes
or otherwise.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> Aside from the crashes, this seems to be a dup of bug 309344.

The scrolling problems you're having are very likely bug 309344.

And at least some of your keyboard problems (though not the crashes) may be
bug 313807.  Are you using a Unicode keyboard layout (such as the "US Extended
keyboard")?  (You choose your keyboard layout in the International preferences
panel, under "Input Menu".)  Do your keyboard problems go away (or lessen) if
you do the following:

1) Install the latest version (0.9.5+b) of the Java Embedding Plugin in your
   /Library/Internet Plug-Ins/ directory, following the instructions at
   http://javaplugin.sourceforge.net/.
2) Remove MRJPlugin.plugin and JavaEmbeddingPlugin.bundle from your Firefox
   distro's Contents/MacOS/plugins directory.

Comment 8

[rhedst1]

> But I'm puzzled by the instructions you've given in comment #5.  When I
> followed them, I didn't end up loading a Java applet at all.  Instead I was
> asked if I wanted to download and run a "Java Web Start" file.

Sorry for the mixup. Let me clarify my steps.

1) Go to the the link I listed in the original bug report. This will load a Java
Applet.
2) Go to the following website: www.java.com/en/games/desktop/sudoku.jsp.
3) Click TRY IT NOW!. A download box should appear asking if you would like to download "Java Web Start". Just cancel out of that.
4) Finally Click on the Search Text Box at the Top Right Corner of the page you ar currently at and try typing something. Your computer should be unable to type anything.
5) If you try to click inside Firefox's URL bar or if you try to hotkey to it,
Firefox will crash.

> Are you using a Unicode keyboard layout (such as the "US Extended
> keyboard")?

Yes, I do use a Unicode keyboard layout. Never thought of it because I mostly type in English. However, I do sometimes type in Japanese, so I have my computer setup for Japanese and I type everything in English under the Romanji setting. I double checked and the Romanji setting is Unicode. I'll try to test switching over to the US Keyboard Layout when I get the chance.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

dveditz, what's the procedure for removing the "security-sensitve" flag on
this bug?

The reporter seems to have set it just because he was reporting a crash (see
comment #4).  Should I just ask the reporter to unset the flag?

I'm asking because this bug is starting to get interesting, and I'd like
others to be able to see what's going on here.

I'm almost certain that the crashes aren't exploitable.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Attachment: More crashes, slighly different

We're finally making some progress!

I followed the procedure you gave in comment #8 and was able to
reproduce both the locked keyboard and similar crashes.  I tested with
Firefox 1.5 and the latest version (0.9.5+b) of the Java Embedding
Plugin -- in other words, I followed the steps I outlined in comment
#7.

I only saw these problems when I was using one of the Kotoeri
(i.e. Japanese) input methods -- the ones I tried were Romaji and
Hiragana.  By the way, the Romaji IME isn't a "Unicode keyboard
layout" (unlike the US Extended keyboard layout), so this isn't a dup
of bug 313807.

I think both problems are triggered by closing the popup window you
get when you click on Sudoku's "TRY IT NOW" button -- though there may
also be other ways to trigger it.

Even with the Romaji and Hiragana IMEs, I didn't see any crashes until
I tried to use a Command+key combination (specifically Command+N to
open a new window, though I'll be others would have the same effect).

I've attached a single file with two crash logs.

Comment 11

[rhedst1]

Attachment: Another Log File that Concerns Unfocusing Window

I cannot remove the Security-Sensitive Bug status. I'm sorry I caused some trouble by doing that, but I did find out something interesting. I was wondering what caused the crash after that download screen loaded and I found this. You don't even need to go to the download screen. Simply unfocus from the current Window. Here are some new steps to cause the application to crash. Please follow the keyboard layout requirements to reproduce this bug.

1) Go to the the link I listed in the original bug report. This will load a
Java Applet.
2) SCROLLING PROBLEM - Go to any website that requires scrolling and try two-finger touch pad scrolling or any other mouse scrolling (Have not tested the mouse scrolling but I have tested the touch pad).
3) KEYBOARD PROBLEM - Now, unfocus from Firefox by clicking outside of the window and then focus back to Firefox. Try highlighting any text field (including the URL bar) and type. You should not be able to type.
4) CRASH FIREFOX - To crash Firefox, simply follow the steps up to this point and try a shortcut command that uses the Command Key. For example, Command + L. This will crash Firefox.

Hope this helps. I also attached another log for the window unfocus.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

> 2) SCROLLING PROBLEM - Go to any website that requires scrolling and try
> two-finger touch pad scrolling or any other mouse scrolling (Have not tested
> the mouse scrolling but I have tested the touch pad).

This is bug 309344.  It's unrelated to your other reports.  Let's drop further
discussion of it from this bug report.

> 3) KEYBOARD PROBLEM - Now, unfocus from Firefox by clicking outside of the
> window and then focus back to Firefox. Try highlighting any text field
> (including the URL bar) and type. You should not be able to type.
> 4) CRASH FIREFOX - To crash Firefox, simply follow the steps up to this
> point and try a shortcut command that uses the Command Key. For example,
> Command + L.  This will crash Firefox.

Neither of these two procedures "work" for me (I don't see either the locked
keyboard or any crashes).  But that doesn't matter a lot, since your other
procedure _does_ work for me.

Comment 13

[rhedst1]

> Neither of these two procedures "work" for me (I don't see either the locked
> keyboard or any crashes).  But that doesn't matter a lot, since your other
> procedure _does_ work for me.

Try switching your keyboard layout to Kotoeri (Japanese Keyboard Layout) and use Romanji as your input for English.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

> Try switching your keyboard layout to Kotoeri (Japanese Keyboard Layout) and
> use Romanji as your input for English.

I did.  No locked keyboard and no crash.  Sorry I didn't mention it.

Comment 15

[rhedst1]

(In reply to comment #14)
> > Try switching your keyboard layout to Kotoeri (Japanese Keyboard Layout) and
> > use Romanji as your input for English.
> 
> I did.  No locked keyboard and no crash.  Sorry I didn't mention it.
> 

Well this has me stumped. I am always able to reproduce the crash with my procedure. I just focus on Finder and focus back to Firefox, and the keyboard lockup and crash can be reproduced. If you are only able to reproduce the crash by cancelling out of the download link, there might be something additional I am missing on my machine.

Comment 16

[rhedst1]

Ok, I have another idea. You said that unfocusing from Firefox does not cause your computer to crash. I experimented with having both a U.S. and Japanese Keyboard layout enabled. I noticed that the application would sometimes switch to the U.S. Keyboard layout if you had previously typed in a text field with that same layout. This would prevent the keyboard from locking up, but as soon as I switched back to the Japanese keyboard layout, it would lock up and then crash if I used the command key. Could you try something for me? Try disabling all keyboard layouts EXCEPT Kotoeri->Romanji. You really do not need to use Romanji. You can use any Kotoeri Keyboard Layout input. Just make sure you disable the other keyboard layouts so that the application does not switch between them. Also, you can type in English with the Romanji input.

After you have done that, try my steps again to crash Firefox by unfocusing from the application, see if that locks the keyboard and crashes your machine.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

I've got a fix for the problems that I was able to reproduce myself (see my
comment #10).  I hope this will also fix the crashes and locked keyboard
problems that you, rhedst1, have reported.

I'll include the fix in my next "nightly" release of the Java Embedding
Plugin, which will probably come out in the next week or two.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

I've (finally) released a new version of the Java Embedding Plugin (0.9.5+d)
that contains the fix I mentioned in comment #17.

http://javaplugin.sourceforge.net/

Please try it out and let me know your results.

To use the new JEP version, you will need to:

1) Install it in /Library/Internet Plug-Ins/ (according to the instructions in
   the JEP Readme).
2) Remove the old JEP files (JavaEmbeddingPlugin.bundle and MRJPlugin.plugin)
   from the Contents/MacOS/plugins/ directory of your Mozilla.org browser(s).

Comment 19

[Adam Smith]

I've tried this on the Alpha 3 version of BonEcho.

The Java handlers provided in the link below (version 0.9.5+e) are incompatible and the browser can't handle the applet.  Going back to the supplied plugin (default with the browser) the applet is able to load.

The only applet I've come across is an Internet banking applet supplied by St. George at http://www.banksa.com.au/.

Replicable: YES
Replication Steps:

1. Log in via web form; redirected to applet
2. Click either "Trust" or "Don't Trust" to accept the signed applet (either has the same result); applet loads in new window

At this stage either window accepts keyboard input.

3. Unable to close the window using Apple-W anymore.
4. Have to close using the red close button.
5. Suddenly, the window underneath will not accept keyboard input.  Apple-W does not work.
6. Press Apple-Q to close application entirely

So, a relaunch fixes the problem.  One problem with this so far is that the only Java applet I've found that does it is my online banking applet which is probably no good to you!  Let me know if there's anything I can do.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3

OS/X 10.4.6 (latest updates at current date)

Comment 20

[Steven Michaud [:smichaud] (Retired)]

I'm not able to confirm any of the problems you report.

Furthermore, the problems reported in comment #19 are unrelated to the
original report.  If you wish to pursue this matter further, please open an
new bug and cc me.

I tested with BonEcho Alpha 3 on OS X 10.4.6 (fully updated).  The applet I
saw wasn't signed (I wasn't prompted to "trust" it) -- so either the bank has
changed its applet since you made your report, or your instructions weren't
precise enough.  (I went to your URL, waited for the page to load, then
clicked the "Logon" button under "Online Services" in the upper right.  I left
"Internet Banking" selected, as it is by default.)

The Java applet launched in a separate window, and (eventually) displayed a
logon form.  The keyboard focus was in the top field of that form.

If I pressed Command-W while the keyboard focus was in this field, an error
message popped up telling me that only numbers were allowed in that field.
The same thing happens in Safari -- so if this is a problem at all, it's a
problem with the applet.  Command-W worked fine when the keyboard focus was no
longer in any of the logon form's fields.  And no matter which way I closed
the applet's window, keyboard input still worked in all of the browser
window's text input fields.

Once again, if you wish to reply to my comment, please do so in a new bug.

Comment 21

[Adam Smith]

> so if this is a problem at all, it's a problem with the applet.

Sorry, my instructions weren't clear enough.  You need to log in past this form in order to launch the applet that causes the bug.  This is why I feel this website is not a particularly easy one to use as a test because only a limited number of people will have access to it but it is the only I know of of that is exhibiting the problem.

I've opted to reply back into the bug instead of replying directly because I feel that there was a key piece of information missing from my original post (that being that the form presented must be passed first.)  Sorry about that.

Once the form is submitted the Java applet is loaded.  When you close that window, the problems described by the original poster occur.  That is why I responded to this bug!  [Step 1 of 3 - has your bug already been reported?]

If think this information is still irrelevant, I will open a new bug at your instruction.

Comment 22

[Steven Michaud [:smichaud] (Retired)]

> You need to log in past this form in order to launch the applet that
> causes the bug.

So you need an account to confirm your report?  If so, I'm not going
to be able to do any tests.

> When you close that window, the problems described by the original
> poster occur.

There are _lots_ of superficial similarities between problems in
different bug reports.  Sometimes (rarely), two different reports turn
out to be related.  There are ways to indicate this when/if it
happens.

It might be best not to pursue this at all until you have a publicly
available URL that demonstrates the problem.  In any case, please open
a new bug when/if you do pursue it.

(Yes, sometimes the same (high frequency) bug gets reported many
times.  But this is clearly not one of those cases.)

Comment 23

[:Felipe Gomes (needinfo for replies!)]

Many years without updates on this bug, and no dupes that we've heard of, so marking it as worksforme.