479942 - shift+space doesn't scroll up with some keyboard layouts

Status: RESOLVED FIXED

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

Description

[Agnès Zietek]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6

If the keyboard layout we use defines something on the Shift+Space key, then we can't scroll up.

Reproducible: Always

Steps to Reproduce:
1. switch to one of the following layout: ch de_mac, fr bepo (last version at http://clavier-dvorak.org), ir, lk, sy syc.
2. scroll down with Space key.
3. try to scroll up with Shift+Space.
Actual Results:  
nothing happens.

Expected Results:  
Should scroll up.

This happens when the layout defines a character on Shift+Space. See the following xkb files extracts, where one defines the characters linked to space key, shift+space, altgr+space, shift+altgr+space:
af:        key <SPCE> { [ space, 0x100200c,    0x10000a0 ] };
ch de_mac: key <SPCE> { [ space, nobreakspace, nobreakspace	]};
fr bepo:   key <SPCE> { [ space, nobreakspace, space,  U202F ] };
ir:        key <SPCE> { [ space, 0x100200c,    nobreakspace ] };
lk:        key <SPCE> { [ space, nobreakspace, 0x0100200c, NoSymbol ] };
sy syc:    key <SPCE> { [ space, 0x100200c	] };

Additionnaly, it's not possible to scroll down with Space when using the following layouts:
bt: key <SPCE> { [ 0x1000F0B, space, 0x1000F0C, nobreakspace ] };
kh: key <SPCE> { [ 0x100200b, space, 0x10000a0, voidsymbol] };

Tested with all this layouts on Ubuntu Intrepid.
Tested with fr-bépo layout on Windows XP using the following software: http://download.tuxfamily.org/dvorak/devel/pkl-fr-dvorak-bepo-1.0rc2.zip (unzip and execute to switch to bépo layout, just quit to return to your previous layout).

Comment 1

[Agnès Zietek]

Same issue on Windows Vista using the software mentionned above
Same issue on Windows Vista using the fr-dvorak-bépo driver found here: http://www.clavier-dvorak.org/wiki/Windows_:_installation

Comment 2

[regain]

On Windows the binding is set in the chrome\toolkit.jar archive, in the content\global\platformHTMLBindings.xml contained file. It specifies the following bindings for the space and shift-space keys:

      <handler event="keypress" key=" " modifiers="shift" command="cmd_scrollPageUp" />
      <handler event="keypress" key=" " command="cmd_scrollPageDown" />

A solution may be to suppress the key attribute (in bépo, the Shift-Space does not produce the " " character, but the non-breakable space) and put instead a keycode attribute with the VK_SPACE value. So, even if the Shift-Space combination does not produce the " " character, it will be recognized with its keycode:

      <handler event="keypress" keycode="VK_SPACE" modifiers="shift" command="cmd_scrollPageUp" />
      <handler event="keypress" keycode="VK_SPACE" command="cmd_scrollPageDown" />

Unfortunately, after altering the platformHTMLBindings.xml file and putting it back in the toolkit.jar archive, the scroll does not work anymore for these two bindings (changing VK_SPACE with another key code as VK_F5 do work correctly).

Comment 3

[Agnès Zietek]

I've tried that with keycode="NS_VK_SPACE" in Ubuntu, and it works, with layouts azerty fr, bépo, bt and ch de_mac.

Comment 4

[regain]

It works also on windows xp with layouts azerty and bépo.

Comment 5

[Agnès Zietek]

Attachment: toolkit.jar including modified global/platformHTMLBindings.xml

This jar file contains the solution mentionned in the comments: in global/platformHTMLBindings.xml, key=" " is replaced by keycode="NS_VK_SPACE", allowing to scroll using the spacebar instead of the space character. This way, it's possible to scroll even if the spacebar produces something other than a space.

Comment 6

[Serge Gautherie (:sgautherie)]

This bug/patch seems nowhere near a state to ask for 'checkin-needed'...

Comment 7

[Serge Gautherie (:sgautherie)]

Can you reproduce with Firefox v3.1b2 / v3.1b3pre ?

Comment 8

[regain]

The bug and its correction could be reproduced with FF 3.1b2 on windows xp.

Comment 9

[Kevin Brosnan]

Reporter posted in bug 450011 wondering if this is a duplicate of that bug.

Comment 10

[Agnès Zietek]

I reproduced the bug with the following version: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090223 Minefield/3.2a1pre (the last that I found of firefox website).
The attached toolkit.jar resolved the bug.

Comment 11

[Serge Gautherie (:sgautherie)]

Attachment: (Bv1) browser-base.inc: Use NS_VK_SPACE

Patch based on toolkit.jar attachment, on behalf of Agnès.

Comment 12

[Serge Gautherie (:sgautherie)]

Fwiw:

Core:
{
http://mxr.mozilla.org/mozilla-central/search?string=NS_VK_SPACE&case=on
NS_VK_SPACE
Found 15 matching lines in 11 files

http://mxr.mozilla.org/mozilla-central/search?string=%5B%5E_%5DVK_SPACE&regexp=on&case=on
[^_]VK_SPACE
Found 11 matching lines in 7 files
}
I don't know what the story is between VK_SPACE and NS_VK_SPACE...

Calendar:
{
http://mxr.mozilla.org/comm-central/search?string=%5B%5E_%5DVK_SPACE&regexp=on&case=on&find=%2Fcalendar%2Fbase%2Fcontent%2Fwidgets%2F
/calendar/base/content/widgets/calendar-list-tree.xml
    * line 1059 -- <!-- use key=" " since keycode="VK_SPACE" doesn't work -->
}
Maybe you want NS_VK_SPACE there ?

Comment 13

[[e-mail]]

Comment on attachment 370129 [details] [diff] [review]
(Bv1) browser-base.inc: Use NS_VK_SPACE

This doesn't really work. Spaces don't generate key codes, they generate char codes, so you'll never get a match. The reason it looks like it works is that (unlike the correct VK_SPACE) an unrecognised keycode of NS_VK_SPACE ends up matching all characters.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This is same as key hell. We should be able to fix this bug easily. I'll post the patches.

Comment 15

[Arthit Suriyawongkul]

this unexpected behavior occurs with Thai keyboard layout in Mac as well.
(but possible to be from different reason .. how to check xkb for th ?)

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Ugh... Looks like the keycode conversion (from GDK_* to Gecko keycode) of Linux is wrong. I need to fix it before this bug...

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.1 Append ASCII spaces into alternative charCodes when space key is pressed on GTK

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 Append ASCII spaces into alternative charCodes when space key is pressed on Windows

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.3 Append ASCII spaces into alternative charCodes when space key is pressed on Mac

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

These patches depend on the patches in bug 630810, bug 677252 and bug 447757.

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

tryserver builds:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-f9352c8ae09f/

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 606117 [details] [diff] [review]
part.1 Append ASCII spaces into alternative charCodes when space key is pressed on GTK

When the physical key can input GDK_space, I think we should always use NS_VK_SPACE for the keycode and append ASCII space for both unshfited and shifted alternative charCodes.

I think that this special behavior is needed only for space key. Because space key is the only key which generates charCode in the special keys around normal printable keys.

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 606118 [details] [diff] [review]
part.2 Append ASCII spaces into alternative charCodes when space key is pressed on Windows

Same way for Windows. Unfortunately, I cannot test this in test_keyCodes.xul because I don't fine the keyboard layouts which inputs non-ASCII-space by space key or shift+space key.

Comment 25

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 606119 [details] [diff] [review]
part.3 Append ASCII spaces into alternative charCodes when space key is pressed on Mac

similar to Mac.

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.1 Append ASCII spaces into alternative charCodes when space key is pressed on GTK

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 Append ASCII spaces into alternative charCodes when space key is pressed on Windows

Comment 28

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.3 Append ASCII spaces into alternative charCodes when space key is pressed on Mac

Comment 29

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 621857 [details] [diff] [review]
part.1 Append ASCII spaces into alternative charCodes when space key is pressed on GTK

Canceling the review.

After implementing KeyboardLayout.key, this might be fixed on XP level.

Comment 30

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch

We can fix this bug easily if we succeed to implement KeyboardEvent.code.

Comment 31

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 8426126 [details] [diff] [review]
Patch

Let's append ASCII whitespace to the end of candidate list for accel key and access key when physical space key is pressed.

Comment 32

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you, Karl.

https://hg.mozilla.org/integration/mozilla-inbound/rev/9a5636240f6c


NOTE: Please do not reopen this bug if this patch doesn't fix on your environment. Instead, please file a new bug and add me to its CC because there should be a bug of computing KeyboardEvent.code value.

Comment 33

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9a5636240f6c