11072 - Apprunner/viewer make keyboard unusable when trying to shut down

Status: VERIFIED WORKSFORME

(SeaMonkey :: General, defect, P3)

Description

[David Hallowell]

Overview Description:
This has only occurred on one Windows 95 machine that I have tested Mozilla on,
other Windows 95 machines, Windows 98 and Linux machines don't suffer from this
problem. When you try to close Mozilla (either apprunner or viewer) the DOS
window (where the debug info is printed) doesn't close and normally produces the
follwoing message:
APPRUNNER caused an invalid page fault in
module RPCRT4.DLL at 0237:70101052.
Registers:
EAX=00000000 CS=0237 EIP=70101052 EFLGS=00010246
EBX=00000000 SS=023f ESP=0096fd88 EBP=0096fdbc
ECX=c114e2d0 DS=023f ESI=81670dc0 FS=4e77
EDX=c0018180 ES=023f EDI=70100000 GS=0000
Bytes at CS:EIP:
ff 70 28 ff 15 78 a0 14 70 c7 05 ec 91 14 70 01
Stack dump:
00000000 70100000 81670dc0 00000000 81624938 0096fdbc bff7411f 0096fd8c 0096fbb8
0096ff78 701090ce 701424d0 ffffffff 0096ff88 bff7c00d 70100000

If you try to close the DOS box by clicking the 'X' in the corner of the title
bar you are asked if you want to terminiate the application. Clicking Yes
normally kills the application but the keyboard will then stop working. No
combination of key presses work. However the mouse still functions normally.

Sometimes the system will not shut down properly because of this bug.
Steps to Reproduce:
 1) Start apprunner or viewer
 2) Close apprunner / viewer
 3) Terminate DOX box application is running in
 4) Try to input data using keyboard.

Actual Results:
Keyboard will not function. NOTE: I've only been able to reproduce this bug on
one particular machine, I've included specifications in 'Additional Information'
below.

Expected Results:
Mozilla exits gracefully and the keyboard still works!

Build Date & Platform Bug Found:
Windows 95 All since M8

Additional Builds and Platforms Tested On:
Linux (RedHat 5.2, 6.0 & SuSE 6.0, 6.1), Windows 98, Windows 95 w/ IE4 Shell all
worked fine.

Additional Information:

First noticed the bug in M8, which was when I started testing Mozilla daily on
this machine. An earlier build did work on this machine but I don't remember
it's build date. I'd donate this machine to you if it was mine ;) but my company
wouldn't be too pleased!

So here are the specifications (this machine also runs Mozilla under Linux with
no probs):
OS: Windows 95 4.00.950 B
IE: 5 5.00.2314.1003 (NOT integrated with desktop)
Intel Pentium II (speed unknown - reported by Win95 as a Pentium Pro)
64MB RAM
Brand: HP Vectra VE
Video: Matrox MGA-G100 AGP
Keyboard: PS/2 using standard Microsoft driver (dated 8-24-1996)
Mouse: PS/2 2 button

Any other information you may need to know about the machine just ask.

Comment 1

[joki (gone)]

I have no idea who's bug this is.  It's apparently a general problem with the
app on Win95.  Handing off to browser-general owner.  Hope someone has a better
guess.

Comment 2

[Chris]

I am also experiencing this bug, again on one machine only. Problems exactly as
described.

Win 95 OSR2 (4.00.950B)
IE 5 5.00.2314.1003
200 MHz Pentium
64 MB Ram
Matrox Mystique video card
Logitech serial mouse

I too have had this problem with various builds for a while, not sure how long.

Comment 3

[Chris]

This bug appears to be identical to #7799. I suggest merging this information
with that bug as it is an ongoing issue with some win95 installations but not
others.

Comment 4

[Chris]

Following the suggestion from bug # 7799, I downloaded and installed the
current Java Runtime Environment v1.2.2 and my problem seems to have gone away.
Mozilla finally crashed running the browser stress test and took Explorer(the
shell, not the browser) with it but I can still type away. I would suggest
anyone encountering this bug install or update their JRE to see if that effects
a cure.

For the developers who might like to troubleshoot this - the last version of
Java was the JDK 1.2, I installed it when it came out and before Sun named the
thing Java2.

Comment 5

[leger]

janc, I believe this no longer occurs...can you verify please.

Comment 6

[Jan Carpenter]

david, is this still happening on your machine?

Comment 7

[David Hallowell]

It was a machine I was using at work and unfortunately I don't work there
anymore so I'm unable to comment, all I can say is that I've never encountered
the problem on any other machine.

Comment 8

[rickg]

Moving to m13 because Joki seems to be distracted.

Comment 9

[joki (gone)]

This came back to event handling, but really, I swear, not an event handling
issue.  I hate to throw it at browser-general again but I don't know a better
place.  Who owns the mozilla.exe app anyway?

Comment 10

[chris hofmann]

need a reproducable test case and some more detail like a stack trace
before we set a milestone for this

Comment 11

[Chris]

My problems with this bug went away after installing Sun's JDK 1.2.2. Prior to
that, I had JDK 1.2.0 installed. I did this after reading bug # 7799, where one
person reported success after removing the JRE 1.2. If you are looking to
reproduce the bug, you might try digging up a copy of JDK 1.2.0 and see if that
causes the keyboard lockup. I could also try the same, especially if the bug is
not reproduceable on the machines you have available.

Comment 12

[leger]

Should we release note the JDK issue?

Comment 13

[Mike McCabe]

JavaScript != Java.

Assigning back to browser-general.

Comment 14

[leger]

Per all the comments in this bug, I believe this is safe to mark WorksForMe.  I 
had no problems outlined here with todays Feb14 Win32 build.  

Comment 15

[leger]

marking Verified.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a3f38fd755b7
[components] Issue https://github.com/mozilla-mobile/android-components/issues/11072: AwesomeBar(): Allow grouping suggestion providers in groups with optional titles