760291 - ui.key.accelKey FF 13b6+ Linux 32 bit over X11 to OSX Lion is broken

Status: RESOLVED DUPLICATE of bug 751749

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

Description

[Adam Moore]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.21 Safari/536.11

Steps to reproduce:

My environment is a little unusual, but it has worked as expected in Firefox 4 through Firefox 12.  I launch 32 bit Linux Firefox without dist extensions on a remote server and send it over X11 to Windows, Linux and Mac clients.  The goal is to make it work like a native browser, so I update prefs.js to remap the key bindings on OSX.  This is done through an extension, but I can reproduce using a stock browser with the following in prefs.js:

user_pref("ui.key.accelKey", 224);
user_pref("ui.key.chromeAccess", 2);
user_pref("ui.key.contentAccess", 2);
user_pref("ui.key.menuAccessKey", 0);
user_pref("ui.key.saveLink.shift", false);

These settings are straight from the greprefs.js file that comes with the Mac version of Firefox.


Actual results:

Remote the browser to Mac OSX Lion the has XQuartz 2.7.2 rc1, and the normal keyboard shortcuts do not work.  Command-t doesn't open a new tab.  The default, Ctrl-t also doesn't open a new tab.  That is just an example, other keyboard shortcuts are broken as well.

I repeated this with the latest Aurora and nightly releases and got the same result.


Expected results:

Using the same settings in Firefox 12, Command-t opens a new tab.  Other keyboard shortcuts work as expected as well.

Comment 1

[Karl Tomlinson (:karlt back Feb 10)]

Are you able to use xev to find out which keysyms are generated by the Command key, please?

Please also paste your xmodmap output.

Comment 2

[Karl Tomlinson (:karlt back Feb 10)]

And output from setxkbmap -print too, please.

Comment 3

[Adam Moore]

xev for ⌘+t

KeyPress event, serial 26, synthetic NO, window 0x600001,
    root 0x481, subw 0x0, time 3804552631, (90,112), root:(90,134),
    state 0x0, keycode 63 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x600001,
    root 0x481, subw 0x0, time 3804552847, (90,112), root:(90,134),
    state 0x10, keycode 25 (keysym 0x74, t), same_screen YES,
    XLookupString gives 1 bytes: (74) "t"
    XmbLookupString gives 1 bytes: (74) "t"
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x600001,
    root 0x481, subw 0x0, time 3804553073, (90,112), root:(90,134),
    state 0x10, keycode 25 (keysym 0x74, t), same_screen YES,
    XLookupString gives 1 bytes: (74) "t"
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x600001,
    root 0x481, subw 0x0, time 3804553073, (90,112), root:(90,134),
    state 0x10, keycode 25 (keysym 0x74, t), same_screen YES,
    XLookupString gives 1 bytes: (74) "t"
    XmbLookupString gives 1 bytes: (74) "t"
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x600001,
    root 0x481, subw 0x0, time 3804553102, (90,112), root:(90,134),
    state 0x10, keycode 25 (keysym 0x74, t), same_screen YES,
    XLookupString gives 1 bytes: (74) "t"
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x600001,
    root 0x481, subw 0x0, time 3804553311, (90,112), root:(90,134),
    state 0x10, keycode 63 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x600001,
    root 0x481, subw 0x0, time 3804553591, (90,112), root:(90,134),
    state 0x0, keycode 63 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x600001,
    root 0x481, subw 0x0, time 3804553767, (90,112), root:(90,134),
    state 0x10, keycode 63 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False



xmodmap:  up to 2 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x40),  Shift_R (0x44)
lock        Caps_Lock (0x41)
control     Control_L (0x43),  Control_R (0x46)
mod1        Mode_switch (0x42),  Mode_switch (0x45)
mod2        Meta_L (0x3f),  Meta_R (0x47)
mod3      
mod4      
mod5      


➜  ~ setxkbmap -print
xkb_keymap {
        xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+empty"      };
        xkb_geometry  { include "pc(pc104)"     };
};

Comment 4

[Karl Tomlinson (:karlt back Feb 10)]

Thanks.  That looks an unusual xmodmap output for a pc104 geometry.
Do you know why it differs from those in Bug 751749 comment 15, for example?
Has xmodmap been used to change the modifiers, perhaps?

(I'm also not familiar with the "empty" symbols.  I wonder what the alpha-numeric keys do, but I assume that is not related to the modifier mapping.)

Comment 5

[Adam Moore]

Right, so in my case I am using a Mac laptop to send these keys over X11 (XQuartz 2.7.2) to my Linux machine.  To complicate things a bit more, the Linux machine I'm testing on is a VirtualBox VM running on the Mac laptop. The keymap you reference appears to be a sun keyboard directly connected to the Linux box.

My Linux VM is minimally configured, and I don't believe there was anything done to modify the defaul key config.  xmodmap wasn't even installed before you asked for its output.

Comment 6

[Andrey Petrov]

It would appear the following commit changes the behavour:

http://hg.mozilla.org/releases/mozilla-release/rev/bbf15bfc5133

Particularly interesting is this:

     // XXX DOM Meta key should be TRUE only on Mac.  We need to discuss this
     //     issue later.
        aInputEvent.isMeta = false;

Previously isMeta would be set that way:

aEvent.isMeta    = (modifierState & GDK_MOD4_MASK) != 0;

So I suspect that is what breaking Adam's case

Comment 7

[Karl Tomlinson (:karlt back Feb 10)]

Ah, I missed that the X11 server is on the MacOSX.  That would explain why things are unusual.

It does seem appropriate to treat a Meta modifier as a DOM Meta modifier on a Mac keyboard, at least.

And yes, Andrey.  That would be the reason.

Comment 8

[Karl Tomlinson (:karlt back Feb 10)]

(In reply to Andrey Petrov from comment #6)
> Previously isMeta would be set that way:
> 
> aEvent.isMeta    = (modifierState & GDK_MOD4_MASK) != 0;

though I don't know why this would have worked as there is no mod4.

Comment 9

[Andrey Petrov]

Karl, what happens if I plug Mac keyboard onto linux/gtk box running Mozilla. Can this be considered a legal case?

Comment 10

[Karl Tomlinson (:karlt back Feb 10)]

I don't have a keyboard to test, but looking at xkeyboard-config (one distributed by Xorg/freedesktop), it looks like the Command keys on a Mac keyboard are usually mapped to Super/Mod4.

Those would have resulted in .isMeta being set prior to bbf15bfc5133.
Now (since bug 61643), Super is mapped to DOM_VK_WIN.

So, yes a Mac keyboard with a linux box should be supported.

The change is a result of xkeyboard-config treating a Mac keyboard like a PC keyboard and Gecko now treating a PC keyboard differently.

Comment 11

[Adam Moore]

The fix in bug 751749, works for me -- marking as a duplicate.