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).

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

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).

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.

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

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.

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

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

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

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

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.

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

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 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.

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

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 ?)

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

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

tryserver builds: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/masayuki@d-toybox.com-f9352c8ae09f/

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 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 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 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.

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

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.

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.