160695 - Mozilla 1.0 on Tru64 Unix not accepting keystrokes

Status: RESOLVED WONTFIX

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[mike deskevich]

I have been having a problem with mozilla on Tru64 unix not accepting input from
the keyboard.  This has been an intermittant problem that started showing up
with version 1.0.  I have been running 0.99 on Tru64 with no problem.  I was
just able to figure out how to reproduce the problem.  When numlock is on,
Mozilla will not accept input from the keyboard.  This only occurs for version
1.0, version 0.99 (the only other version i have to test with) works fine no
matter what the numlock state is.

When Mozilla isn't accepting input from the keyboard, it appears to affect
everything: you cannot type in the url box, you cannot type in any text boxes on
webpages, and you cannot use the keyboard to scroll on a webpage.  However you
can still use the arrowkeys to navigate in the menus.

Feel free to contact me if you need more info: mikedeskevich@_NOSPAM_myrealbox.com

Comment 1

[Matthias Versen [:Matti]]

Do you see this always if you enable numlock ?
or only sometimes ?

Do you see a caret ?

see also bug 82534

Comment 2

[Matthias Versen [:Matti]]

-> Keyboard Nav

via mail:
yes, this always occurs when numlock is on.  no other states (scroll
lock, caps lock) affect the input.

unlike bug 82534 i do see a caret when no matter what the numlock state.

i confused me for a while because everything looked normal, it just
wouldn't take the input i was typing.

since i submitted the bug, i have had a two other Tru64 users verify
that this happens to them too.  and they see the same problems.

Comment 3

[Aaron Leventhal]

-> Akkana, UNIX accesibility

Comment 4

[Akkana Peck]

This will probably need help from someone on a platform that has the problem.  I
suspect that it's an issue with some library we use, like gdk.  The best
approach would be to follow the event in nsGtkEventHandler.cpp and see whether
it's being passed correctly; if it never gets to nsGtkEventHandler, then it's
not a moz bug.

Comment 5

[Silvia Zhao]

This bug can not be reproduced on Solaris. When Num Lock is on, the keyboard
works well.

Comment 6

[Martin Mokrejs]

I see this bug time to time also on my Linux Gentoo laptop with

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030826

I have the numlock turned off as I don't use the numeric keyboard, so I dought
if that's really the cause.

Comment 7

[Bob Vickers]

(In reply to comment #6)
I think this is the same as bug 140050, and I suspect it happens with X servers
that map the numlock key to mod4. If you type 'xmodmap -pm' you get a list of
keyboard modifiers, and both Tru64 and NCD Exploras report mod4 being triggered
by Numlock. You can stop the problem happening by typing
   xmodmap -e 'remove mod4 = Num_Lock'

You can make the problem start happening (possibly on any X server) by typing
   xmodmap -e 'add mod4 = Num_Lock'

I am not an expert on this stuff, but I suspect Mozilla should be changed
so that mod4 does not change keyboard behaviour. I have seen a similar problem
with mwm and the mod2 and mod5 modifiers (every X server seems to have a
different convention for how it interprets the numlock key).

Comment 8

[Laxmi Harikumar]

The fix for the bug 43433 treats the key mapped to mod4 as Meta key.
Since Num_Lock is mapped to mod4 on Tru64, it behaves as the Meta key.
(anEvent.isMeta is set to 1 when Num_Lock is ON)

Suggested fix:

Index: nsGtkEventHandler.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtk/nsGtkEventHandler.cpp,v
retrieving revision 1.186
diff -c -r1.186 nsGtkEventHandler.cpp
*** nsGtkEventHandler.cpp       2 Jul 2004 12:08:38 -0000       1.186
--- nsGtkEventHandler.cpp       2 Nov 2004 06:54:40 -0000
***************
*** 380,386 ****
--- 380,390 ----
      anEvent.isShift = (aGEK->state & GDK_SHIFT_MASK) ? PR_TRUE : PR_FALSE;
      anEvent.isControl = (aGEK->state & GDK_CONTROL_MASK) ? PR_TRUE : PR_FALSE;
      anEvent.isAlt = (aGEK->state & GDK_MOD1_MASK) ? PR_TRUE : PR_FALSE;
+ #if defined(OSF1)
+     anEvent.isMeta = PR_FALSE;
+ #else
      anEvent.isMeta = (aGEK->state & GDK_MOD4_MASK) ? PR_TRUE : PR_FALSE;
+ #endif
    }
  }
***************
*** 395,401 ****
--- 399,409 ----
      anEvent.isShift = (aGEK->state & GDK_SHIFT_MASK) ? PR_TRUE : PR_FALSE;
      anEvent.isControl = (aGEK->state & GDK_CONTROL_MASK) ? PR_TRUE : PR_FALSE;
      anEvent.isAlt = (aGEK->state & GDK_MOD1_MASK) ? PR_TRUE : PR_FALSE;
+ #if defined(OSF1)
+     anEvent.isMeta = PR_FALSE;
+ #else
      anEvent.isMeta = (aGEK->state & GDK_MOD4_MASK) ? PR_TRUE : PR_FALSE;
+ #endif
  
      anEvent.charCode = nsConvertCharCodeToUnicode(aGEK);
      if (anEvent.charCode) {

If there are no problems with this fix, can it be checked in?

Comment 9

[Bob Vickers]

(In reply to comment #8)
I'm guessing by visual inspection that this fix only fixes the bug on Tru64 and
not on other X servers that exhibit the same problem (e.g. NCD Exploras, see bug
140050). It may also do the wrong thing if the program runs on Tru64 but
displays on some other X server. Ideally the fix needs to examine at runtime the
characteristics of the X server, because at compile-time it does not know what
kind of display will be used.

Still, if you can fix it for the case when both client and server are Tru64 that
may well be better than nothing.

I am happy to supply xmodmap output or other diagnostic info about NCD Exploras
if that helps.

Bob

Comment 10

[Laxmi Harikumar]

In the fix for the  bug 43433, the code in nsGtKEventHandler.cpp has been changed
from (version 1.167):
anEvent.isMeta = PR_FALSE; //(aGEK->state & GDK_MOD2_MASK) ? PR_TRUE : PR_FALSE;
to (version 1.168):
anEvent.isMeta = (aGEK->state & GDK_MOD4_MASK) ? PR_TRUE : PR_FALSE;
This was a fix for Sun Solaris.

Before this fix(i.e. pre Mozilla 1.0) when
anEvent.isMeta = PR_FALSE
"Num_Lock" problem was not seen.
Also Solaris and Linux are free from the "Num_Lock" problem even with
the fix i.e. Mozilla 1.0 onwards. (I guess Num_Lock is not mapped to
mod4 in these cases).

In the fix suggested here we are trying to go back to the
anEvent.isMeta = PR_FALSE;
state and put the fix as "#if defined(OSF1)" because
we did not want to break others, as it has been working well with Solaris,Linux
etc.

Since other X servers like NCD Exploras are exhibiting same problem, 
one solution could be to ifdef
anEvent.isMeta = (aGEK->state & GDK_MOD4_MASK) ? PR_TRUE : PR_FALSE;
with a Solaris flag. (Bug 43433 is for Sun Solaris).
That way the problem gets narrowed down to cases where the compilation
happens on Sun Solaris. 
But we do not have the expertise to deal with this problem.

Comment 11

[Bob Vickers]

I understand why you want to avoid breaking other architectures, but your method
of testing the architecture is fundamentally flawed, because it only works in
the special (though common) case where the X server is the same architecture as
the X client. Any attempt to fix this problem using compile-time Ifdefs will
fail if the program is displaying on a remote X server with different
architecture. This will often be true in a thin client environment, and these
will increasingly form an important part of the market (e.g. kiosks).

Let me emphasise the problem *does* occur on Linux systems. It causes great
confusion here, where we have Firefox running on Linux servers but displaying on
NCD Exploras (or to use X terminology, the X client is Linux and the X server is
NCD). 

Bob

(In reply to comment #10)
> Also Solaris and Linux are free from the "Num_Lock" problem even with
> the fix i.e. Mozilla 1.0 onwards. (I guess Num_Lock is not mapped to
> mod4 in these cases).
> 

Comment 12

[Bob Vickers]

What is the procedure for getting the OS classification of this bug corrected?
Or should I submit a new bug reporting that it happens on Linux too?

I'm guessing that if we could get the Linux experts looking at it we might make
more progress. 

Bob

Comment 14

[Matthias Versen [:Matti]]

True64 build support got removed