Open Bug 1599345 Opened 6 years ago Updated 1 year ago

At least one youtube keyboard shorcut doesnt work with firefox and AZERTY keyboard

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Version:
70 Branch
Platform:
Unspecified
Windows 7
Type:
defect

Tracking

()

Project Flags:
Webcompat Priority P3

People

(Reporter: karlcow, Unassigned)

References

(
URL
)

Details

As reported on https://webcompat.com/issues/44772

Hello there. Noticed a weirg bug with firefox, youtube and azerty keyboard. I've tested this on firefox 64bits 70.0.1, but it's apparently not new since it can be done on basilisk and waterfox as well. Happens both on windows 7 and 10.

I'm used to browsing youtube and speed up or slow down videos using my azerty keyboard, shortcuts are SHIFT + , to slow down and SHIFT + ; to speed up

Works well on all version of chrome and all chromium based browsers I tried in the past.

But any browser based on firefox, I can slow down, but I can't speed up, SHIFT + ; doesn't work. I've tried all other possible key combinations, none speeds up youtube videos, while on firefox-based browser and AZERTY keyboard

If I switch my layout to qwerty using ALT+SHIFT, I can then slow down and speed up using my physical SHIFT + ; and SHIFT + : shortcuts which are respectively < and > on the qwerty layout, so it's specific to AZERTY layout, maybe other non-QWERTY layouts but I couldn't test this.

This bug is definitely a deal breaker for me as youtube and speeding and slowing videos is most of my daily web browsing so I'll be returning to a chromium browser for now unfortunately

I've posted this issue on reddit /r/firefox and was told it would be useful to post it here.

Does anyone have azerty keyboard for testing?
(I'll ask French folks)
https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html can be useful for testing what kind of
keyCode/charCode/key/code we get with shift + ',' and shift + ':'

Component: DOM: Events → DOM: UI Events & Focus Handling
Priority: -- → P3

Hello. You don't need an azerty keyboard to test, just add the azerty layout.
The mapping qwerty > azerty is:
m is ,
M is ?
, is ;
< is .

On a QWERTY keyboard, you use '<' and '>' to change the youtube speed, but if you switch to an AZERTY layout, then the keys which change the speed are 'M' and '<' (and '<' doesn't change the speed in Firefox only, which is the problem reported)

Not sure if it helps but here are two recordings of keypress of the '<' key (white: edge & chrome, black: firefox). First with an AZERTY layout, then with a QWERTY layout: https://prnt.sc/XYgkK7uQUPET
I can see only the legacy keyCode being different.

Webcompat Priority: revisit → P3
Severity: normal → S3

Hello, I was having the very same issue since I switched back to Ubuntu/Firefox a couple of months ago.

I decided to investigate/address it today, and just found out that the following Firefox extension circumvents the issue by sending the correct Chromium keycodes, apparently:

https://addons.mozilla.org/en-US/firefox/addon/yt-azerty-shortcuts-fixer/
https://github.com/OrmazdFR/yt-azerty-shortcuts-fixer

Perhaps this could be useful in fixing it in Firefox directly?
Regards,
Eric.

Hello everyone,

I was having a similar issue as well with the US Dvorak layout. I'm currently running Firefox 122.0.1 on Ubuntu 22.04 (X11) and can confirm the bug still exists. I eventually got tired of not having this YouTube shortcut and decided to dive into the Firefox code. I don't fully understand how input processing is meant to work in Firefox, but through tracing the bug I gained an insight into what might be the issue, and even found a workaround for my system.

WORKAROUND: In your OS settings, try setting your desired layout as your FIRST choice instead of your second (or higher) choice. For my system, setting Dvorak as my first choice removed the issue completely, but ONLY FOR DVORAK. With QWERTY as my second choice, it was now the buggy one. If that doesn't work, try removing the second layout option completely and see if that fixes it. I've only tested this with Ubuntu 22.04, so YMMV. Please let me know if this works or doesn't work for you.

I'll now jump into what I found in the code (changeset 773923:09e686c99291). As I was looking at the code, I became aware of a concept called a "group". My guess is that it refers to keyboard layouts that contain multiple sub-layouts as part of their operation. Here's a basic example: https://en.wikipedia.org/wiki/ISO/IEC_9995#Groups

In widget/gtk/nsGtkKeyUtils.cpp, line 1290, the function keymapWrapper->IsLatinGroup() is called to check if the currently selected "group" is an ASCII compatible layout (non-Latin characters aren't supported by ASCII).

if (!keymapWrapper->IsLatinGroup(aGdkKeyEvent->group)) {
    // Handle the non-Latin layout...

Both QWERTY and Dvorak are Latin layouts, so IsLatinGroup() should return true. However, if either of these layouts are selected as the second option in the OS, this function returns false. The subsequent logic then handles this as a non-Latin layout, corrupting the keycode.

Working off my limited knowledge, I think one of two things might be going on. The first possibility is that there's a difference between what Firefox understands aGdkKeyEvent->group to mean and what GDK understands it as. In the docs for GDK it simply says that it's the keyboard group. However, if the layout is the second choice in the OS, it gets set to 1 instead of 0. My feeling is that it should return 0 regardless of system keyboard selection, but apparently GDK thinks of it as the system layout selection index.

The second possibility is that there's a bug in GDK, and that it shouldn't be returning 1 for the second system layout. I almost have to lean toward this possibility for the following reason. Here's our function IsLatinGroup() in its entirety:

bool KeymapWrapper::IsLatinGroup(guint8 aGroup) {
  GdkKeymapKey* keys;
  gint count;
  bool result = false;
  if (gdk_keymap_get_entries_for_keyval(mGdkKeymap, GDK_a, &keys, &count)) {
    for (gint i = 0; i < count; ++i) {
      if (keys[i].level != 0 && keys[i].level != 1) {
        continue;
      }
      if (keys[i].group == aGroup) {
        result = true;
        break;
      }
    }
    g_free(keys);
  }
  return result;
}

All this function really does in my case is call gdk_keymap_get_entries_for_keyval() with the key value for "A" and checks if the currently selected group is represented in the "keys" list. However, on my machine, even with two layouts configured on my OS, only one entry is ever returned, with the "group" attribute only ever being 0. This means that every time this is called on my second system layout, the function returns false.

My reasoning for leaning toward calling this a bug in GDK is due to a seeming inconsistency in how it conceptualizes groups. For aGdkKeyEvent->group it seems to think of it as the index of your current OS layout. For gdk_keymap_get_entries_for_keyval() it seems to think of groups as being limited in scope to a single layout.

I hope this makes sense so far. I debated making this a separate bug report since the original post mentioned Windows 7 and 10, and I reference GDK which is a non-Windows system. However, a subsequent poster mentioned this bug in Ubuntu, and it's possible that some mistaken assumptions about keyboard handling carried over to the Windows implementation of this as well. Let me know if any more information or exploration is needed. Hopefully we can fix this long-standing nuisance for all affected multi-layout users out there.

The plot thickens! I got to thinking about the fact that IsLatinGroup() checks the key value "A" when looking for groups, and realized that the "A" key is the same between the two layouts. I was curious about whether gdk_keymap_get_entries_for_keyval() removes extraneous groups if the key code is identical between them, and it turns out it does!

The "A" key was likely chosen arbitrarily, but to confirm my hunch, I changed the code to look it up with the one other key in common between my two layouts: the letter "M". It behaves identically to the letter "A", only returning a single entry for group 0. However, if I change gdk_keymap_get_entries_for_keyval() to look up with any other letter in the alphabet, it returns three entries.

[
{keycode: 0x1F, group: 0, level: 0},
{keycode: 0x36, group: 1, level: 0},
{keycode: 0x36, group: 2, level: 0}
]

For reference, I changed the routine to look up the letter "C" (0x36), which is "I" (0x1F) in Dvorak. (Keycode Reference) Dvorak was my first system layout, and QWERTY my second. The outcome was the same regardless of system layout selected. This one change "fixed" the YouTube issue for me, though it's obviously not even close to a solution.

Since the commonality of "A" key location between a user's configured system layouts can change how the bug expresses, I imagine this only adds to confusion about the issue. Ultimately, there seems to be a misunderstanding at play with this implementation.

For people who ends up here, found a workaround with this extension: https://addons.mozilla.org/en-US/firefox/addon/yt-azerty-shortcuts-fixer/

@wolf.morgan10 it was already shared by ultrashricco two years ago.

Hi !

I just ran into the same problem, and found this bug report from Reddit -> webcompat -> Firefox Bugzilla

I can confirm that the extension https://addons.mozilla.org/en-US/firefox/addon/yt-azerty-shortcuts-fixer/ works for me, but i was looking at an upstream fix, considering the bug has been since a while now.

Any update on this issue ?
FF 133.0.3 - Ubuntu
Thanks !

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