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

RESOLVED FIXED in mozilla32

Status

()

Core
Event Handling
RESOLVED FIXED
9 years ago
2 years ago

People

(Reporter: Agnès Zietek, Assigned: masayuki)

Tracking

(Blocks: 1 bug)

Trunk
mozilla32
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [key hell] When you want to reopen this bug, please read the comment 32, first.)

Attachments

(1 attachment, 8 obsolete attachments)

2.34 KB, patch
karlt
: review+
Details | Diff | Splinter Review
(Reporter)

Description

9 years ago
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).
(Reporter)

Comment 1

9 years ago
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

9 years ago
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).
(Reporter)

Comment 3

9 years ago
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.
Keywords: checkin-needed

Comment 4

9 years ago
It works also on windows xp with layouts azerty and bépo.
(Reporter)

Comment 5

9 years ago
Created attachment 364284 [details] [diff] [review]
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.
This bug/patch seems nowhere near a state to ask for 'checkin-needed'...
Keywords: checkin-needed
Version: unspecified → Trunk
Can you reproduce with Firefox v3.1b2 / v3.1b3pre ?

Comment 8

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

Comment 9

9 years ago
Reporter posted in bug 450011 wondering if this is a duplicate of that bug.
(Reporter)

Comment 10

9 years ago
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.
Created attachment 370129 [details] [diff] [review]
(Bv1) browser-base.inc: Use NS_VK_SPACE

Patch based on toolkit.jar attachment, on behalf of Agnès.
Attachment #364284 - Attachment is obsolete: true
Attachment #370129 - Flags: superreview?(neil)
Attachment #370129 - Flags: review?(neil)
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 ?
Assignee: nobody → az24
Status: UNCONFIRMED → ASSIGNED
Component: Keyboard Navigation → Keyboard: Navigation
Ever confirmed: true
Product: Firefox → Core
QA Contact: keyboard.navigation → keyboard.navigation
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2a1
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.
Attachment #370129 - Flags: superreview?(neil)
Attachment #370129 - Flags: superreview-
Attachment #370129 - Flags: review?(neil)
Attachment #370129 - Flags: review-
Attachment #370129 - Attachment is obsolete: true
This is same as key hell. We should be able to fix this bug easily. I'll post the patches.
Assignee: az24 → masayuki
Component: Keyboard: Navigation → Widget
QA Contact: keyboard.navigation → general
Target Milestone: mozilla1.9.2a1 → ---
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...
Depends on: 447757
Depends on: 631165
Depends on: 677252
No longer blocks: 450011
Duplicate of this bug: 450011
Blocks: 65896
Severity: minor → normal
Whiteboard: [key hell]
Created attachment 606117 [details] [diff] [review]
part.1 Append ASCII spaces into alternative charCodes when space key is pressed on GTK
Created attachment 606118 [details] [diff] [review]
part.2 Append ASCII spaces into alternative charCodes when space key is pressed on Windows
Created attachment 606119 [details] [diff] [review]
part.3 Append ASCII spaces into alternative charCodes when space key is pressed on Mac
These patches depend on the patches in bug 630810, bug 677252 and bug 447757.
Depends on: 630810
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.
Attachment #606117 - Flags: review?(karlt)
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.
Attachment #606118 - Flags: feedback?(karlt)
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.
Attachment #606119 - Flags: feedback?(karlt)
Created attachment 621857 [details] [diff] [review]
part.1 Append ASCII spaces into alternative charCodes when space key is pressed on GTK
Attachment #606117 - Attachment is obsolete: true
Attachment #621857 - Flags: review?(karlt)
Attachment #606117 - Flags: review?(karlt)
Created attachment 621858 [details] [diff] [review]
part.2 Append ASCII spaces into alternative charCodes when space key is pressed on Windows
Attachment #606118 - Attachment is obsolete: true
Attachment #621858 - Flags: feedback?(karlt)
Attachment #606118 - Flags: feedback?(karlt)
Created attachment 621859 [details] [diff] [review]
part.3 Append ASCII spaces into alternative charCodes when space key is pressed on Mac
Attachment #606119 - Attachment is obsolete: true
Attachment #621859 - Flags: feedback?(karlt)
Attachment #606119 - Flags: feedback?(karlt)
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.
Attachment #621857 - Flags: review?(karlt)
Attachment #621858 - Flags: feedback?(karlt)
Attachment #621859 - Flags: feedback?(karlt)
Depends on: 680830
Depends on: 842927
Attachment #621857 - Attachment is obsolete: true
Attachment #621858 - Attachment is obsolete: true
Attachment #621859 - Attachment is obsolete: true
Component: Widget → Event Handling
Depends on: 865649
No longer depends on: 680830
Created attachment 8426126 [details] [diff] [review]
Patch

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.
Attachment #8426126 - Flags: review?(karlt)
Attachment #8426126 - Flags: review?(karlt) → review+
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.
Whiteboard: [key hell] → [key hell] When you want to reopen this bug, please read the comment 32, first.
https://hg.mozilla.org/mozilla-central/rev/9a5636240f6c
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Depends on: 1259679
You need to log in before you can comment on or make changes to this bug.