Bug 534580 - Shortcut keys are not respecting the currently selected keyboard layout
Summary: Shortcut keys are not respecting the currently selected keyboard layout
Status: CLOSED DUPLICATE of bug 533395
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.7.3   Edit
Hardware: PC Linux
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: needinfo
Depends on:
Blocks:
 
Reported: 2018-05-11 09:12 EDT by Michael Tänzer CLA
Modified: 2018-05-11 16:35 EDT (History)
1 user (show)

See Also:


Attachments
xkbcomp $DISPLAY output.xkb (83.39 KB, application/octet-stream)
2018-05-11 09:13 EDT, Michael Tänzer CLA
no flags Details
xmodmap -pke (24.22 KB, text/plain)
2018-05-11 09:13 EDT, Michael Tänzer CLA
no flags Details
Debug options (145 bytes, text/plain)
2018-05-11 09:15 EDT, Michael Tänzer CLA
no flags Details
Debug log (33.83 KB, text/plain)
2018-05-11 09:15 EDT, Michael Tänzer CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Tänzer CLA 2018-05-11 09:12:13 EDT
When I use any keyboard shortcut (e.g. CTRL+C and CTRL+V) Eclipse does not respect the keyboard layout I have selected, but seems to use the US keyboard instead. This seems like the same behaviour seen in Bug 61190 but I am on Eclipse 4.7.3a, so this should have been fixed.

I use a linux OS (Ubuntu Gnome 16.04.4) which has libgtk in version 3.18.9. The keyboard layout I use in my session is the Neo keyboard layout. The system keyboard layout is set to normal German layout (difference to the US layout: X and Z are switched). I did not change the layout while Eclipse was running.

More system information
-----------------------

Output of `setxkbmap -query`:
rules:      evdev
model:      pc105
layout:     de,de,us,gb
variant:    neo,,,

Attached keybindings.log contains output from `eclipse -debug options` with attached options file where I did the following operations:
1. CTRL+C (on a US layout this would have been CTRL+R). Copy seems to work
2. CTRL+V (on a US layout this would have been CTRL+W). This closes the editor window.
3. CTRL+Ä (on a US layout this would have been CTRL+C).
4. CTRL+P (on a US layout this would have been CTRL+V). This pastes the text previously copied.

xev for the same commands shows the following events:
KeyPress event, serial 34, synthetic NO, window 0x2c00001,
    root 0x136, subw 0x0, time 18666336, (979,209), root:(1114,408),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x2c00001,
    root 0x136, subw 0x0, time 18667046, (979,209), root:(1114,408),
    state 0x4, keycode 27 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (03) ""
    XmbLookupString gives 1 bytes: (03) ""
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x2c00001,
    root 0x136, subw 0x0, time 18667157, (979,209), root:(1114,408),
    state 0x4, keycode 27 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (03) ""
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x2c00001,
    root 0x136, subw 0x0, time 18667576, (979,209), root:(1114,408),
    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x2c00001,
    root 0x136, subw 0x0, time 18672320, (979,209), root:(1114,408),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x2c00001,
    root 0x136, subw 0x0, time 18672989, (979,209), root:(1114,408),
    state 0x4, keycode 54 (keysym 0x63, c), same_screen YES,
    XKeysymToKeycode returns keycode: 27
    XLookupString gives 1 bytes: (03) ""
    XmbLookupString gives 1 bytes: (03) ""
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x2c00001,
    root 0x136, subw 0x0, time 18673084, (979,209), root:(1114,408),
    state 0x4, keycode 54 (keysym 0x63, c), same_screen YES,
    XKeysymToKeycode returns keycode: 27
    XLookupString gives 1 bytes: (03) ""
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x2c00001,
    root 0x136, subw 0x0, time 18673392, (979,209), root:(1114,408),
    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False


Attached output of `xkbcomp $DISPLAY output.xkb` and `xmodmap -pke`

-- Configuration Details --
Product: Eclipse 4.7.3.20180405-1200 (org.eclipse.epp.package.cpp.product)Installed Features:
 org.eclipse.platform 4.7.3.v20180330-0640
Comment 1 Michael Tänzer CLA 2018-05-11 09:13:17 EDT
Created attachment 274000 [details]
xkbcomp $DISPLAY output.xkb
Comment 2 Michael Tänzer CLA 2018-05-11 09:13:59 EDT
Created attachment 274001 [details]
xmodmap -pke
Comment 3 Michael Tänzer CLA 2018-05-11 09:15:24 EDT
Created attachment 274002 [details]
Debug options
Comment 4 Michael Tänzer CLA 2018-05-11 09:15:54 EDT
Created attachment 274003 [details]
Debug log
Comment 5 Leo Ufimtsev CLA 2018-05-11 11:32:45 EDT
Looks like dupliate of:
533395 – [Gtk][Regression] Keyboard shortcuts are taken from first item in "Input Source" instead of currently active input, thus breaking custom layouts (e.g Dvorak/Colemak/AZERTY) if it's not default layout.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=533395

Can you confirm?
Comment 6 Michael Tänzer CLA 2018-05-11 14:54:40 EDT
(In reply to Leo Ufimtsev from comment #5)
> Can you confirm?

Yes, indeed it seems like the same bug although the description is misleading because it also happens (as in my case) when it is the first input source.

*** This bug has been marked as a duplicate of bug 533395 ***
Comment 7 Leo Ufimtsev CLA 2018-05-11 16:35:45 EDT
(In reply to Michael Tänzer from comment #6)
> (In reply to Leo Ufimtsev from comment #5)
> > Can you confirm?
> 
> Yes, indeed it seems like the same bug although the description is
> misleading because it also happens (as in my case) when it is the first
> input source.
> 
> *** This bug has been marked as a duplicate of bug 533395 ***

I see. Can you suggest a better title?