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.

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

Summary: [Gtk][Regression] Keyboard shortcuts are taken from first item in "Input Sour...

Status:	VERIFIED FIXED

Alias:	None

Product:	Platform
Classification:	Eclipse Project
Component:	SWT (show other bugs)
Version:	4.8
Hardware:	PC Linux

Importance:	P3 normal with 6 votes (vote)
Target Milestone:	4.10 M1
Assignee:	Xi Yan
QA Contact:

URL:
Whiteboard:
Keywords:	helpwanted, regression, triaged

Duplicates (3):	531378 534580 535204 (view as bug list)
Depends on:
Blocks:

Reported:	2018-04-09 16:00 EDT by Leo Ufimtsev
Modified:	2018-09-24 09:59 EDT (History)
CC List:	12 users (show)

See Also:	534580 Gerrit Change Git Commit

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Leo Ufimtsev

2018-04-09 16:00:37 EDT

Continuation from:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=531378

Strange regression in 4.8 in keyboard shortcuts.
Keyboard shortcuts are taken from 'first item' in 'input sources' instead of the current active keyboard layout.
(As mentioned in: https://bugs.eclipse.org/bugs/show_bug.cgi?id=532574#c5)

Environments:
Fedora 27, Gtk3.22.26 (Wayland/x11)
RHEL 7.5 (beta), Gtk3.22.26

Steps to reproduce:
- Install OS with "English (US)" as default qwerty layout.
- Download nightly eclipse (April 9th 2018)
- Go to Region & Language.
-- Add US -> "Dvorak" layout.
-- The input source list should still show (in this order).
   English (US)
   English (Dvorak)
- Open Eclipse, make new project & open a java  file.
- try to copy and paste a line via physical buttons "Ctrl-i & Ctrl-. " (which translate to ctrl+c & ctrl+v).

Expected behavior:
- Copy and paste

Actual behavior:
- Nothing, but physical Ctrl-c & Ctrl-v behave as dictated by layout that is first in the list of input sources.

Known workaround:
- Set alternative layout as default (e.g Dvorak/Colemak), then keyboards work as expected.

Theory:
- Could be this guy:
https://git.eclipse.org/r/#/c/22713/
But need to bisect to tell for sure.

Comment 1 Leo Ufimtsev

2018-04-09 16:02:39 EDT

*** Bug 531378 has been marked as a duplicate of this bug. ***

Comment 2 Julius LAWSON

2018-04-30 16:42:46 EDT

As the reporter of bug 532574 (closed as a duplicate), I answer the question I was asked by Alexander Kurtakov : I'm using Eclipse Oxygen.2 Release (4.7.2), Build id: 20171218-0600.

Regards.

Comment 3 Leo Ufimtsev

2018-04-30 16:57:41 EDT Comment hidden (obsolete)

I asked gtk folks if they know of a clean way to reparent gdk windows.

If we can't find a good way, we might use gtk_reparent_widget(..) for photon and look for a better solution later.

######################################

Original mail to gtk-devs:

Hello guys,

gtk_widget_reparent ()  was deprecated in 3.14. It's suggested to use remove/add container instead. gtk_widget_reparent (..) was subsequently removed in gtk4.

The problem with the suggested "removing/adding container" is that it doesn't reparent child's gDk windows.

i.e: the method originally also reparented subwindows:
GtkWidget.c: gtk_widget_reparent ( ) {

      g_object_ref (widget);
      gtk_container_remove (GTK_CONTAINER (priv->parent), widget);
      gtk_container_add (GTK_CONTAINER (new_parent), widget);
      g_object_unref (widget);
      ...
      gtk_widget_reparent_subwindows (widget, gtk_widget_get_parent_window (widget));
      gtk_widget_reparent_fixup_child (widget, gtk_widget_get_parent_window (widget));
      ...
}

If we only remove/add container (with g_object_ref(widget)), we get the error:
'(Eclipse:17380): Gdk-WARNING **: gdk_window_new(): parent is destroyed'

In the interest of future Gtk4 compatibility, other than manually implementing
'*_subwindows()' and *_fixup_child', is there away to do a reparenting via api
that also reparents gdk subwindows?

Thank you for your help.

Comment 4 Jean-Marie Aubry

2018-05-01 03:13:52 EDT Comment hidden (obsolete)

Hi Leo, I think I missed a step here. Is the gtk reparenting issue causing our keyboard shortcuts malfunction?

Comment 5 Leo Ufimtsev

2018-05-01 10:04:07 EDT Comment hidden (obsolete)

(In reply to Jean-Marie Aubry from comment #4)
> Hi Leo, I think I missed a step here. Is the gtk reparenting issue causing
> our keyboard shortcuts malfunction?

Ops, I accidentally wrote the comment into the wrong bug. (I had multiple tabs open in my browser). 

The comment above was suppose to go into this bug:
534089 – [GTK3] Tabfolder setControl(..) breaks with a table that has composite controls.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=534089

Please ignore comment #3.

Comment 6 Aaron Wells

2018-05-04 01:59:30 EDT

I've experience the same bug using Dvorak on Ubuntu.

Environment:
Ubuntu 16.04
Ubuntu MATE 1.154, GTK 3.18.9

Oxygen.3a Release (4.7.3.a)
Build id: 20180405-1200

It took me a while to realize the problem was the keyboard layout not being recognized! I actually came to the bug tracker looking for a bug about the Undo shortcut (Ctrl+z) toggling line comments. Which is, of course, because the Dvorak "z" key is the Qwerty "/" key. :)

I actually had Dvorak at the top of the list of layouts in my Keyboard Preferences control panel, but Eclipse was mapping keyboard shortcuts to the second layout on the list:

1. "English (US) English (Dvorak)"
2. "Maori" [which is a Qwerty layout]

As a workaround, I removed the other keyboard layout, so that Dvorak is my only active keyboard layout.

Comment 7 Leo Ufimtsev

2018-05-04 09:20:41 EDT

(In reply to Aaron Wells from comment #6)
> I've experience the same bug using Dvorak on Ubuntu.

Thank you for your report.

Always feel free to vote for bugs, we pay attention to these metrics when deciding which things to fix.

I never noticed the issue originally because I use Colemak as my primary keyboard layout and don't really use other layouts. Further Colemak has similar shortcuts (Ctrl-Z/X/C). It's more noticeable on Dvorak.

We should fix this thou.

Comment 8 Michael TÃ¤nzer

2018-05-11 14:54:40 EDT

*** Bug 534580 has been marked as a duplicate of this bug. ***

Comment 9 Michael TÃ¤nzer

2018-05-11 15:07:03 EDT

For me this also happens when the selected keyboard layout is the first input source. I have the following input sources set:
1. German (Neo 2) => XVLCW (weird)
2. German => QWERTZ
3. English (US) => QWERTY
4. English (UK) => QWERTY

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

It seems that the fallback is not the "normal" German layout, because the CTRL+Z shortcut is mapped to the position it would have on a QWERTY keyboard. So my first guess would be that it always falls back to the US layout if the first input is not recognized.

For more information and log files see bug 534580

Comment 10 Andrey Loskutov

2018-06-03 05:17:12 EDT

*** Bug 535204 has been marked as a duplicate of this bug. ***

Comment 11 Leo Ufimtsev

2018-06-29 16:11:17 EDT

Returning bug back to queue as I'm transferring into Consulting.

Might be something for Xi Yan to work on.

Comment 12 Xi Yan

2018-08-24 14:03:56 EDT

This is a feature/bug of GNOME where the shortcut keybindings persists as the default one when changing layout. This behaviour affects all applications (gedit, terminal, ...), so I don't think there is anything we can fix. See the long discussion about it here: https://bugzilla.gnome.org/show_bug.cgi?id=162726

Comment 13 Julius LAWSON

2018-09-03 10:14:24 EDT

Hi Xi Yan.

You wrote: "This behaviour affects all applications (gedit, terminal, ...)". But it was not the case for me: only Eclipse was impacted (gedit and the terminal were working fine). This bug is so massive when it hurts you that you can't pass through it: if it affects gedit (for instance) you can't ignore it.

And the Gnome bug you point us to is closed as fixed for 2 years.

Regards.

Comment 14 Ansgar Radermacher

2018-09-03 10:49:16 EDT

(In reply to Julius LAWSON from comment #13)
> Hi Xi Yan.
> 
> You wrote: "This behaviour affects all applications (gedit, terminal, ...)".
> But it was not the case for me: only Eclipse was impacted (gedit and the
> terminal were working fine). This bug is so massive when it hurts you that
> you can't pass through it: if it affects gedit (for instance) you can't
> ignore it.
> 
> And the Gnome bug you point us to is closed as fixed for 2 years.
> 
> Regards.

I confirm that all other applications are working fine (though I primarily use KDE) and that the bug is quite annoying. Please, do not close it as won't fix.

Comment 15 Patrick Scheid

2018-09-17 08:12:27 EDT

(In reply to Xi Yan from comment #12)
> This is a feature/bug of GNOME where the shortcut keybindings persists as
> the default one when changing layout. This behaviour affects all
> applications (gedit, terminal, ...), so I don't think there is anything we
> can fix. See the long discussion about it here:
> https://bugzilla.gnome.org/show_bug.cgi?id=162726

I can also confirm, that Eclipse and Eclipse-based applications like "DBeaver" are the only affected applications. All other applications work very fine.

Comment 16 Ansgar Radermacher

2018-09-17 08:54:15 EDT

Please re-open or give good reasons not to do so.

Comment 17 Xi Yan

2018-09-17 14:41:41 EDT

(In reply to Ansgar Radermacher from comment #16)
> Please re-open or give good reasons not to do so.

Thank you for your comment. Re-opening this ticket.

I did some more investigation regarding this issue and found out: 

1) On Fedora 28, shortcuts are always taken from 'primary layout  (first item)' in Gedit/terminal/Eclipse, which was the case for me when I closed the ticket.

2) On Ubuntu (and likely many others), the shortcuts works fine with Gedit/terminal but not eclipse. 

3) Using the following snippet, Text and StyledText behaves differently to copy/paste shortcuts. Under Dvorak, Ctrl-i & Ctrl-. shortcuts copy/paste in Text (expected behavior), but ctrl+c & ctrl+v shortcuts copy/paste in StyledText. This seems to be the same issue. 

============================== Snippet ================================

public static void main (String [] args) {
	Display display = new Display ();
	Shell shell = new Shell(display);

	shell.setLayout(new FillLayout());

	StyledText styledText = new StyledText(shell, SWT.BORDER);
	styledText.setText("StyledText");

	Text text = new Text(shell, SWT.BORDER);
	text.setText("Text");

	shell.open ();
	while (!shell.isDisposed ()) {
		if (!display.readAndDispatch ()) display.sleep ();
	}
	display.dispose ();
}

================================================================

Comment 18 Eclipse Genie

2018-09-17 16:58:05 EDT

New Gerrit change created: https://git.eclipse.org/r/129573

Comment 19 Eclipse Genie

2018-09-19 12:47:44 EDT

Gerrit change https://git.eclipse.org/r/129573 was merged to [master].
Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=95e0cb1ec0942a6f24e42af56a2cb1c308d6d9b8

Comment 20 Xi Yan

2018-09-20 08:56:37 EDT

(In reply to Eclipse Genie from comment #19)
> Gerrit change https://git.eclipse.org/r/129573 was merged to [master].
> Commit:
> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/
> ?id=95e0cb1ec0942a6f24e42af56a2cb1c308d6d9b8

In master now. This patch should fix the issue on X11, nothing can be done on Wayland afaict since it's an issue with gtk applications as well.

Comment 21 Xi Yan

2018-09-24 09:59:59 EDT

Verified in I20180923-1800.