| Summary: | AltGr-up and AltGr-down keyboard shortcuts in the editor to navigate to the next and previous strings do not work | ||
|---|---|---|---|
| Product: | [Retired] Zanata | Reporter: | Runa Bhattacharjee <runab> |
| Component: | Usability | Assignee: | zanata-dev-internal <zanata-dev-internal> |
| Status: | CLOSED WONTFIX | QA Contact: | Ding-Yi Chen <dchen> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 1.3 | CC: | ankit, ngoswami, sflaniga, sshedmak, zanata-bugs |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-09-30 06:07:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Runa Bhattacharjee
2011-09-27 03:43:22 UTC
Correction: These shortcuts do not work with the Right Alt key only, for some browser versions. Navigation to previous and next translation unit(s) works for me in translation editor when using Alt_L modifier (tested with firefox-6.0.2-1.fc15.x86_64 & chromium 13.0.782.215-1.fc15.x86_64). Note: above behaviour doesn't work with Alt_R modifier. Navigation to previous and next entry works works for me in translation editor only while using Alt_L modifier. With Alt_R it doesn't work. Browser: firefox-3.6.20-2.el6_1.x86_64 OS: el6.x86_64 One user has mentioned that he could not replicate the bug using firefox-6.0.2-1.fc15.x86_64, although another user (comment #2) could replicate with the same version. From Comment 2 and Comment 3, required behaviour of navigation to next and previous translation unit(s) works with Alt_L (i.e. Alt left) modifier, and hence expected results are obtained. From Comment 1, Comment 2 and Comment 3, required behaviour of navigation to next and previous translation unit(s) doesn't work with Alt_R (i.e. Alt right) modifier, and hence expected results are not obtained. It maybe the keyboard layout problem.
sandeep, what's your keyboard layout? Does the Right Alt is shown as "AltGr"?
Or please type following in a terminal window:
1. xev
2. And press following:
alt_L-UP
alt_R-UP
3. close xev
4. Paste the result, which should somewhat looks like:
KeyPress event, serial 33, synthetic NO, window 0x5800001,
root 0xb1, subw 0x0, time 24921477, (144,19), root:(146,109),
state 0x0, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 33, synthetic NO, window 0x5800001,
root 0xb1, subw 0x0, time 24921596, (144,19), root:(146,109),
state 0x8, keycode 111 (keysym 0xff52, Up), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 33, synthetic NO, window 0x5800001,
root 0xb1, subw 0x0, time 24921651, (144,19), root:(146,109),
state 0x8, keycode 111 (keysym 0xff52, Up), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 33, synthetic NO, window 0x5800001,
root 0xb1, subw 0x0, time 24921785, (144,19), root:(146,109),
state 0x8, keycode 116 (keysym 0xff54, Down), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 33, synthetic NO, window 0x5800001,
root 0xb1, subw 0x0, time 24921872, (144,19), root:(146,109),
state 0x8, keycode 116 (keysym 0xff54, Down), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
(In reply to comment #6) > It maybe the keyboard layout problem. > Yes. I agree with you. > sandeep, what's your keyboard layout? Does the Right Alt is shown as "AltGr"? > Yes, Right Alt is shown as "AltGr". This has been done to add "Rupee" currency sign to key bearing numeral '4'; and key to choose 3rd level was 'Right Alt'. xev output: ============ KeyPress event, serial 32, synthetic NO, window 0x3600001, root 0xb8, subw 0x0, time 636197, (790,272), root:(791,361), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 32, synthetic NO, window 0x3600001, root 0xb8, subw 0x0, time 636335, (790,272), root:(791,361), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False Therefore, required behaviour of navigation to next and previous translation unit(s) works with Alt_R (i.e. Alt right) modifier, and hence expected results are obtained. This concludes that this bug can't be reproduced henceforth. Confirmed that the Right Alt+up/down works if the 'Indian Keyboard with Rupee Sign' is disabled. Unfortunately, for Indian users this won't be feasible. With the plans of using Alt_Gr on a much larger scale for various Indian input methods (also to be included in ibus), this particular shortcut may have to be explicitly restricted to the Left Alt. (In reply to comment #7) > (In reply to comment #6) > > It maybe the keyboard layout problem. > > > > Yes. I agree with you. > > > sandeep, what's your keyboard layout? Does the Right Alt is shown as "AltGr"? > > > > > Yes, Right Alt is shown as "AltGr". > > This has been done to add "Rupee" currency sign to key bearing numeral '4'; and > key to choose 3rd level was 'Right Alt'. > > > xev output: > ============ > KeyPress event, serial 32, synthetic NO, window 0x3600001, > root 0xb8, subw 0x0, time 636197, (790,272), root:(791,361), > state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, > XKeysymToKeycode returns keycode: 92 > XLookupString gives 0 bytes: > XmbLookupString gives 0 bytes: > XFilterEvent returns: False > > KeyRelease event, serial 32, synthetic NO, window 0x3600001, > root 0xb8, subw 0x0, time 636335, (790,272), root:(791,361), > state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, > XKeysymToKeycode returns keycode: 92 > XLookupString gives 0 bytes: > XFilterEvent returns: False > > > Therefore, required behaviour of navigation to next and previous translation > unit(s) works with Alt_R (i.e. Alt right) modifier, and hence expected results > are obtained. > > This concludes that this bug can't be reproduced henceforth. Just as I suspected, "Normal" Alt produce 0x8, while AltGr produce 0x80 Thus Alt-Up is not the same with AltGr-Up BTW, does AltGr-Up, AltGr-Down, AltGr-PgUp, AltGr-PgDn clash with your input method or keyboard layout? So, is this a request to enable AltGr-Up/Down/PgUp/PgDn, or to avoid them, and keep them free for input methods? Do we need to do anything? Ideally to avoid Alt_Gr. At present it conflicts with the 'Indian Keyboard with the Rupee Sign'. However, going forward it will conflict with IBus as well, due to the Enhanced Inscript keyboards for the Indian languages with heavy usage of Alt_Gr. These are currently in the testing phase. https://fedorahosted.org/inscript2/ As modifier AltGr might clash when inputting Indic, this bug will be closed as WONTFIX |