411005 - both Dvorak and QWERTY keybindings active in text fields when using dvorak layout

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

After setting the GNOME keyboard layout to Dvorak, both the Dvorak and the QWERTY cut, copy, and paste keybindings are active in HTML and XUL text fields like the Description field into which I am typing this bug description and the Firefox search box.

In other words, both Ctrl-X (where "X" is the key marked "B" on a QWERTY keyboard) and Ctrl-Q (where "Q" is the key marked "X" on a QWERTY keyboard) cut the selected text; both Ctrl-C (where "C" is "I" on a QWERTY keyboard) and Ctrl-J (where "J" is "C") copy the selected text; and both Ctrl-V (where "V" is ".") and Ctrl-K (where "K" is "V") paste the text on the clipboard.

Outside text fields, however, only the Dvorak keybindings are active, which means that if you are outside a text field and type Ctrl-K ("V") twice, the first time focuses the Firefox search box (since Ctrl-K is the keybinding for focusing that box) while the second pastes the contents of the clipboard into the box.

When active, QWERTY keybindings override Dvorak ones, so if the location bar is focused, then Ctrl-K only pastes into the bar; it doesn't also take you to the search box.

I wonder if this has anything to do with us using native widgets and GNOME's dubious position in one of the many GNOME bug reports about this problem <http://bugzilla.gnome.org/show_bug.cgi?id=162726> that users of multiple Latin layouts mostly want the same set of keybindings in all their layouts, even though Mac and Windows both provide user choice in this regard, as noted in my comment on that bug <http://bugzilla.gnome.org/show_bug.cgi?id=162726#c36>.

In any case, it's a regression from Firefox's previous behavior and not particularly useful.  I suppose one could argue that Firefox should be like GNOME and apply only the QWERTY bindings everywhere, but I think we're better off reverting to our previous behavior of applying just the Dvorak keybindings across the app.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Seems more likely to be a GTK widget bug (or GTK bug) rather than a Firefox bug.

Comment 2

[Christian Persch (GNOME) (away; not receiving bug mail)]

Don't think this is a bug in gtk. I rather suspect that the patch from bug 69230 caused this.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Ah, yes, seems likely.

Comment 4

[Alexander L. Slovesnik]

That's probably caused by patch from Bug 406407, not Bug 69230
Bug 406407 dealt with accelerators in textEdit fields.

Comment 5

[Karl Tomlinson (:karlt)]

I suspect the change is mostly due to bug 406407, but I'm having trouble understanding why this is considered a regression rather than preferred behavior. 

(In reply to comment #0)
> After setting the GNOME keyboard layout to Dvorak, both the Dvorak and the
> QWERTY cut, copy, and paste keybindings are active in HTML and XUL text fields
> like the Description field into which I am typing this bug description and the
> Firefox search box.

This is the behavior I expect from looking at the GTK+ implementation in gdk_keymap_translate_keyboard_state and I believe it is intentional.

> 
> In other words, both Ctrl-X (where "X" is the key marked "B" on a QWERTY
> keyboard) and Ctrl-Q (where "Q" is the key marked "X" on a QWERTY keyboard) cut
> the selected text; both Ctrl-C (where "C" is "I" on a QWERTY keyboard) and
> Ctrl-J (where "J" is "C") copy the selected text; and both Ctrl-V (where "V" is
> ".") and Ctrl-K (where "K" is "V") paste the text on the clipboard.

Isn't it useful that, where possible, a key-combination (not character-combination) shortcut works in all layouts?

> 
> Outside text fields, however, only the Dvorak keybindings are active, which
> means that if you are outside a text field and type Ctrl-K ("V") twice, the
> first time focuses the Firefox search box (since Ctrl-K is the keybinding for
> focusing that box) while the second pastes the contents of the clipboard into
> the box.

Outside the text field is our implementation in nsWindow.cpp (not the GTK+ implementation provided by bug 406407).  (There may be some problems here with punctation as I suggested in bug 69230 comment 175, but that is not what is being reported here.)

> 
> When active, QWERTY keybindings override Dvorak ones, so if the location bar is
> focused, then Ctrl-K only pastes into the bar; it doesn't also take you to the
> search box.

"When [the QWERTY layout is] active"?
It seems desirable that the current active layout determines priorities?

Is the issue here that you think our keybindings should override gnome keybindings?

This behavior is not too different from the "Return" key starting a new line in text input boxes but submitting forms elsewhere.

> 
> I wonder if this has anything to do with us using native widgets and GNOME's
> dubious position in one of the many GNOME bug reports about this problem
> <http://bugzilla.gnome.org/show_bug.cgi?id=162726> that users of multiple Latin
> layouts mostly want the same set of keybindings in all their layouts, even
> though Mac and Windows both provide user choice in this regard, as noted in my
> comment on that bug <http://bugzilla.gnome.org/show_bug.cgi?id=162726#c36>.

It is related to the GTK native keybinding implementation used in text fields.

> 
> In any case, it's a regression from Firefox's previous behavior and not
> particularly useful.  I suppose one could argue that Firefox should be like
> GNOME and apply only the QWERTY bindings everywhere, but I think we're better
> off reverting to our previous behavior of applying just the Dvorak keybindings
> across the app.
> 

It is very useful for non-Latin keyboards.

Does GNOME really only respect QWERTY bindings, not Dvorak even when in a Dvorak layout?

Comment 6

[Evgeniy Ivanov]

I know the place cased this bug:
+          gtk_bindings_activate_event(GTK_OBJECT(mNativeTarget),
+                                      static_cast<GdkEventKey*>(guiEvent->nativeMsg));  //is used for ctrl+x/c/v shortcuts, see bug 406407
+  if (!gHandled)
!!!!!!!!!!!    gtk_bindings_activate(GTK_OBJECT(mNativeTarget),
+                          keyCode, GdkModifierType(modifiers));  /*is used for non-shortcuts operations (I didn't find the way to remove it and
+                                                                  to make !!!!!!!!!!! gtk_bindings_activate_event work alone */

I think it may be fixed in 1 minute. I will download the source and try it.

Comment 7

[Evgeniy Ivanov]

Hm... I guess, the problem is in the patch for Bug 69230.
Ctrl+Dvorak_B is changed to Ctrl+Dvorak_X, because this patch changes the active layout. Anywhere I will debug these 2 places.
Firefox building firs time is a very hard deal - too long process

Comment 8

[Evgeniy Ivanov]

Ok, I've tested firefox from cvs. Everything seems to be ok. ctrl+QWERTY_c (I mean the physical key) doesn't work. Ctrl+v and Double usage of Ctrl+QWERTY_k is ok.
I guess ctrl+QWERTY_c (the copied text is appeared in the buffer, but it is not used as paste text) is related to the Bug 407604.

Comment 9

[Karl Tomlinson (:karlt)]

(In reply to comment #0)
> When active, QWERTY keybindings override Dvorak ones, so if the location bar is
> focused, then Ctrl-K only pastes into the bar; it doesn't also take you to the
> search box.

(I misinterpreted this on the first read, sorry, but this is the core problem:)

Even when the Dvorak layout is active it seems that some QWERTY bindings override Dvorak bindings.

This is because QWERTY native text field bindings are overriding Dvorak application bindings.

The desirable behavior I assume would be to check keybindings in this order (when in a text field with Dvorak layout active):

1) Native Dvorak text field bindings.
2) Dvorak application bindings.
3) Native QWERTY text field bindings.
4) QWERTY application bindings.

Currently we're doing this:

1) Native Dvorak text field bindings.
2) Native QWERTY text field bindings.
3) non-punctuation Dvorak application bindings.
4) If the key is punctuation in the Dvorak layout
   then check QWERTY application bindings.

What would be most useful in implementing the desirable behavior is a means to determine whether there is an (active?) application/XUL binding for a particular key.  Is there a way to get a list of XUL keybindings?

Comment 10

[Evgeniy Ivanov]

Hm...
Karl, I'm not sure that is's done in a way you've described.
Text Fields keybindings are activated by gtk_bindings_activate_event. This function takes care about layouts.
As I saw everything is ok in my system. So, the question is what does author use (version of mozilla and gtk)?
The good way is to write mochitest for this problem (I don't remember JS, so it's not for me).

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

For what it's worth, I don't see this, and I'm glad I don't.  If my keyboard is set to Dvorak, that's what the keys on my keyboard should mean.  (Would you want somebody in France with an AZERTY keyboard to quit when they tried to select all?)

That said, Myk suggested this might have something to do with having multiple keyboard configurations.

Comment 12

[Karl Tomlinson (:karlt)]

(In reply to comment #10)
> Hm...
> Karl, I'm not sure that is's done in a way you've described.
> Text Fields keybindings are activated by gtk_bindings_activate_event. This
> function takes care about layouts.

Yes, this function takes care of layouts for native text field keybindings, but I'm assuming that if no native keybinding is found then we fallback to our application/XUL keybindings, which is not happening if there is a match in a not-currently selected group.

> As I saw everything is ok in my system. So, the question is what does author
> use (version of mozilla and gtk)?

Do you have two US layouts enabled: one QWERTY and one DVORAK?
Both we need to be enabled concurrently to see this issue.

Comment 13

[Karl Tomlinson (:karlt)]

(In reply to comment #11)
> (Would you want somebody in France with an AZERTY keyboard to quit when they
> tried to select all?)

This won't happen for two reasons:
1) Ctrl-Q is not bound to Quit
2) It sounds like text field bindings are prioritized.

What may happen is that when a French user switches to a US layout (but still has the AZERTY layout enabled) and tries Ctrl-Q (hoping it may have been bound to Quit), they end up selecting all.

If Ctrl-Q is bound to Quit, then I think we all agree that selecting all would be undesirable behavior.

What is perhaps up for debate is whether we should fallback to enabled-but-not-currently-selected layouts when there is no binding in the current layout.

> That said, Myk suggested this might have something to do with having multiple
> keyboard configurations.

I'm sure it does.

Myk, do Dvorak keyboard users often also have a QWERTY layout enabled?
Is that because Dvorak users often wish to switch to QWERTY easily?

Comment 14

[Karl Tomlinson (:karlt)]

If someone with a US (non-)localization switches from a US to a Hebrew layout in order to type Hebrew, and wishes to select all, do we think they should:

1) switch back to US layout to type Ctrl-A,
2) just use Ctrl with the key that has an A on it, or
3) use Ctrl-<key for suitable hebrew character>

If 3 is desirable, then perhaps an alternative approach to falling back to different layouts (2) is to have multiple keybindings (in all localizations - i.e. no localization) for each command, so that every script (that has few enough characters such that there are key-assignments for the characters) has accelerators for the associated layouts.

Comment 15

[Myk Melez [:myk] [@mykmelez]]

> Isn't it useful that, where possible, a key-combination (not
> character-combination) shortcut works in all layouts?

It's not useful for me, since I can only memorize a single keyboard layout, thus I never know what other characters a given key might represent, and having that key do anything other than what it would do in the active layout is unexpected.


> Is the issue here that you think our keybindings should override gnome
> keybindings?

Not really, although I prefer the Firefox keybindings (which follow the active layout) to the GNOME keybindings (which ignore the active layout in this situation).

The primary issue is just that our keybindings are inconsistent.  In particular, Ctrl-K does one thing when a text field is focused and something else when any other element is focused.


> Does GNOME really only respect QWERTY bindings, not Dvorak even when in a
> Dvorak layout?

Yes, if both Dvorak and QWERTY (U.S. English) layouts are selected in the Keyboard Preferences dialog, even if Dvorak is made the "default" layout in that dialog.

According to http://bugzilla.gnome.org/show_bug.cgi?id=162726 , this is intentional, as "the real use case for having multiple layouts is languages like Greek, Hebrew, Russian, Arabic, where the user switches back and forth between the two layouts frequently and where the set of key symbols on the two layouts is distinct." <http://bugzilla.gnome.org/show_bug.cgi?id=162726#c1>

Another GTK+ developer claims that "having more than one latin layout installed is a corner case." <http://bugzilla.gnome.org/show_bug.cgi?id=162726>

Plenty of commenters on that bug disagree, however, including not only Dvorak users but French users who also use an English layout and don't like their applications to quit when they try to "select all."

And there are plenty of duplicate bugs and comments from frustrated users, so there's clearly a demand for different behavior.  As I pointed out in a comment on the bug <http://bugzilla.gnome.org/show_bug.cgi?id=162726#c36>, both Mac OS X and Windows give users the option to use either QWERTY or layout-dependent keybindings for a number of layouts.


> The desirable behavior I assume would be to check keybindings in this order
> (when in a text field with Dvorak layout active):

From what I can tell, there are two camps in the debate, one that wants the active layout to solely determine the keybindings and another that wants a single (QWERTY) layout to solely determine the keybindings.  I'm not aware of any folks who want the keybindings to be a mixture of both layouts.


> If Ctrl-Q is bound to Quit, then I think we all agree that selecting all would
> be undesirable behavior.

Yes, and note that over in bug 189290 I've attached a patch to bind Ctrl-Q to Quit.


> Myk, do Dvorak keyboard users often also have a QWERTY layout enabled?
> Is that because Dvorak users often wish to switch to QWERTY easily?

Some of us do.  I'm not sure how common it is, but I expect it's mostly about allowing others to use our computers easily.  That's the reason in my case, and it sounds like it's Michael Leuchtenburg's reason in http://bugzilla.gnome.org/show_bug.cgi?id=162726#c7 .


> If someone with a US (non-)localization switches from a US to a Hebrew layout
> in order to type Hebrew, and wishes to select all, do we think they should:
>
> 1) switch back to US layout to type Ctrl-A,
> 2) just use Ctrl with the key that has an A on it, or
> 3) use Ctrl-<key for suitable hebrew character>

I'm not sure what the right solution is for multiple layouts where one of them is non-Latin, so I'm inclined to follow the GTK+ folks' recommendation for option 2 in that case.

Comment 16

[Karl Tomlinson (:karlt)]

(In reply to comment #15)
Thanks for explaining, Myk.

> > Does GNOME really only respect QWERTY bindings, not Dvorak even when in a
> > Dvorak layout?
> 
> Yes, if both Dvorak and QWERTY (U.S. English) layouts are selected in the
> Keyboard Preferences dialog, even if Dvorak is made the "default" layout in
> that dialog.

It seems that GTK+ has a very similar issue to us in that it is trying to fallback only when there is no binding for the key in the current layout, but there is no one list of active bindings.
QWERTY bindings appear to override Dvorak bindings even when Dvorak is selected (I'm assuming) because fallback to another layout is performed before checking for matches in the selected layout on other widgets.

The algorithm would probably be tolerable for most users if there were a way to test check all sources of keybindings in the one place.  I suspect this is not easy to do with GTK+'s event bubbling/capturing.

Things would be improved with the algorithm in the patch at

http://bugzilla.gnome.org/show_bug.cgi?id=162726#c20

Basically the concept is that if the keybinding existed in the current layout but the user didn't use that binding then they probably don't want that keybinding from another layout.  Thus if one Latin layout is selected, then (usually) no other Latin layouts are tried, but layouts with different scripts are tried for fallback.

The algorithm falls apart though when there are bindings for characters in more than one script.

> From what I can tell, there are two camps in the debate, one that wants the
> active layout to solely determine the keybindings and another that wants a
> single (QWERTY) layout to solely determine the keybindings.

I think we can fix this up enough to satisfy Latin users in the first camp.  I imagine the second (QWERTY) camp might be able to change their xkb variant setup so that different codes are sent when Ctrl is active.

Interestingly kxkb only enables one layout at a time for Latin layouts.  For other scripts there is a maximum of two layouts active, the option second of can only be a Latin layout which is to pick up Latin shortcuts.

Comment 17

[Karl Tomlinson (:karlt)]

Evgeniy, I suspect that gtk_bindings_activate_event is actually no longer needed for the case of using Ctrl-<Latin-key> combinations from non-Latin layouts, now that the patch in bug 69230 mutates Ctrl-<non-Latin-key> codes into Latin codes.
i.e. keyCode is now (usually) Latin when Ctrl is active.  Are you able to try commenting out this call, please?  (It works in my testing.)

gtk_bindings_activate_event is more appealing that mutating the event, but it causes us to suffer http://bugzilla.gnome.org/show_bug.cgi?id=162726 and we currently still need the mutation for XUL keybinding matching which doesn't yet use any Latin-fallback strategy.

One group of people that could be helped by gtk_bindings_activate_event are those that have non-Latin native keybindings, as the information here has been removed from keyCode.  We could use gtk_bindings_activate_event (or perhaps gtk_bindings_activate with nativeMsg->keyval) only when nativeMsg->keyval != keyCode.  i.e. (mostly) only when not in a Latin layout.

The group of people that would not be happy then would be those that have non-Latin bindings that they want to use from a Latin layout.  Maybe this group is almost as small as those that have two Latin layouts enabled concurrently ;)

Comment 18

[Evgeniy Ivanov]

Ok, I will take (after 22-25 Jan, have exams).

Comment 19

[Evgeniy Ivanov]

(In reply to comment #17)
> Evgeniy, I suspect that gtk_bindings_activate_event is actually no longer
> needed for the case of using Ctrl-<Latin-key> combinations from non-Latin
> layouts, now that the patch in bug 69230 mutates Ctrl-<non-Latin-key> codes
> into Latin codes.
You're true. I tested it and shortcuts really work without it. But I didn't found the place where they are activated.

> i.e. keyCode is now (usually) Latin when Ctrl is active.  Are you able to try
> commenting out this call, please?  (It works in my testing.)
Only the problem described in the Bug 399939. But I've never used alt+*.

> gtk_bindings_activate_event is more appealing that mutating the event, but it
> causes us to suffer http://bugzilla.gnome.org/show_bug.cgi?id=162726 and we
> currently still need the mutation for XUL keybinding matching which doesn't yet
> use any Latin-fallback strategy.
If to be sincere, I understand it very badly. You want such thing: try to work with ctrl+Latin and if it fails, try ctrl+native? Am I right?
  
> 
> One group of people that could be helped by gtk_bindings_activate_event are
> those that have non-Latin native keybindings, as the information here has been
> removed from keyCode.  We could use gtk_bindings_activate_event (or perhaps
> gtk_bindings_activate with nativeMsg->keyval) only when nativeMsg->keyval !=
> keyCode.  i.e. (mostly) only when not in a Latin layout.
gtk_bindings_activate is old and has problems with localization.

The question is what we want? To fix Bug 399939 and to remove gtk_bindings_activate_event to fix this? I have 2 ideas how to fix 399939, so will try.

Comment 20

[Evgeniy Ivanov]

Attachment: fixes the problem (if key is latin gtk_bindings_activate will be used)

If I will be success in gtk-patching (the similar thing should be added to the gtk_bindings_activate_event), this patch will not be useful.
Of course the patch from Bug 406407 may be rejected to fix it too. But if some changes with non-Latin - Latin conversion occur here we will have a bug.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+      /* used for non-shortcuts operations (I didn't find the way to remove it and
+      to make gtk_bindings_activate_event work alone 
+      Also it is used to fix Bug 411005, caused by bug in gtk_bindings_activate_event (see http://bugzilla.gnome.org/show_bug.cgi?id=162726)
+      While all non-Latin characters are converted to Latin in nsWindows.cpp
+      gtk_bindings_activate_event won't be used. But this routine is preferable */
+      activated = gtk_bindings_activate(GTK_OBJECT(mNativeTarget),
+                            keyCode, GdkModifierType(modifiers)); 

All in { }

+  if (!gHandled &&
+      !activated &&
+       guiEvent &&

Aren't gHandled and activated always false here?

Comment 22

[Evgeniy Ivanov]

Attachment: It might be clear

(In reply to comment #21)
> All in { }
I've changed the patch.

> +  if (!gHandled &&
> +      !activated &&
> +       guiEvent &&
> 
> Aren't gHandled and activated always false here?
No. For alt+shift (as example) they're true. But gtk_bindings_activate_event doesn't handle it (I checked them at the end of function). So I removed it.

Also the code in comment might work correctly if GTK bug would be fixed. I suggest to stay it in the comment. We spoke to much about it in 2 Bug pages just to remove it.
And if somebody change converting non-Latin to Latin it would be a bug here, so it's much better not to remove the comment. Of course it's IMHO. I haven't any experience in such big projects (or even smaller :) ).

Comment 23

[Reed Loden [:reed]]

Checking in widget/src/gtk2/nsNativeKeyBindings.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsNativeKeyBindings.cpp,v  <--  nsNativeKeyBindings.cpp
new revision: 1.7; previous revision: 1.6
done