2069698 - Super stopped working as modifier when entering text

Status: VERIFIED FIXED

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

Description

[Alexander]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:155.0) Gecko/20100101 Firefox/155.0

Steps to reproduce:

Environment: Linux, native Wayland (about:support shows Window Protocol: wayland; Desktop Environment: Gnome)

Steps:

1. Start Firefox with a fresh profile
2. Open about:config and set ui.key.accelKey to 91 (Super / Win).
3. Restart Firefox.
4. Focus the address bar, type some text.
5. Press Super+A, Super+C, Super+V.
6. Press Super+T, Super+W

Actual results:

This is the behavior in 155:
Super+letter inserts the letter in the focused field.
Super+T / Super+W do not open/close tabs.

When not entering text (focus is somewhere on a page, not in the address bar or input/textarea), it works as expected (Super+C copies text into the clipboard, Super+T opens a new tab, Super+W closes the tab)

Expected results:

This is the behavior in 154:
Super+A / Super+C / Super+V: select all / copy / paste.
Super+T / Super+W: new tab / close tab.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alexander]

FWIW, an AI-assisted investigation suggested that it's another regression of 2051354.

Here is the summary on the investigation:

  Root cause

  Between 154 and 155, Bug 2051354 reworked IMContextWrapper::OnCommitCompositionNative. In 154, if IME committed a character matching the key (no real composition), Firefox always fell back to normal keydown/keypress — so modifiers
  (including Super→Meta) stayed on the event and accel shortcuts worked.

  In 155, that fallback is gated by EditorMayHandleKeyPressEventAsTextInput(), which is false when Control/Alt/Meta are held:

   widget/gtk/nsGtkKeyUtils.cpp lines 1123-1127

  bool KeymapWrapper::EditorMayHandleKeyPressEventAsTextInput(
      guint aGdkModifierState) {
    const Modifiers modifiers = ComputeKeyModifiers(aGdkModifierState);
    return !(modifiers & (MODIFIER_CONTROL | MODIFIER_ALT | MODIFIER_META));
  }

  With ui.key.accelKey = 91, Super is Meta. So for Super+T / Super+W:

  1. IME (ibus/fcitx) filters the key and commits "t" / "w".
  2. EditorMayHandle… is false → no mGraphemeClusterFallbackToKeyEvent.
  3. Code falls through to DispatchCompositionCommitEvent → character is inserted.
  4. OnKeyEvent returns eHandled → chrome never sees a Meta key event → no new tab / close tab.

Comment 3

[Alexander]

Attachment: input.log

Attaching the log (MOZ_LOG="IMEHandler:5,KeyboardHandler:5" firefox) of me focusing the Firefox window (address bar), typing "firefox.com" and the pressing Super+T, Super+W twice and then Super+A

Comment 4

[BugBot [:suhaib / :marco]]

:masayuki, since you are the author of the regressor, bug 2051354, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh, yeah, this is a really tricky case... DOM Meta modifier which is activated by Super, Hyper or Meta of Linux modifier does not change the character and we used the fallback path to dispatch eKeyDown event as is. However, currently, it's treated as a text input with a special feature of the IME.

Comment 6

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2051354

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 2069698 - Make `IMContextWrapper::OnCommitCompositionNative` use `eKeyDown` event if DOM `Ctrl`, `Alt` or `Meta` is pressed and the commit string is the same as the key r=m_kato!

IME may send commit signal without the composing state when
user presses Super or something. Then, if the commit string is the
same as the character introduced by the key press, the user may want
to use a shortcut key or an access key. Therefore, we need to dispatch
eKeyDown instead of composition events or a content event with
Process eKeyDown since the global key handler needs to handle the
key event as a shortcut key.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The latest test build. Could you check whether this fix the bug in your environment too?

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4075182cae4c
https://hg.mozilla.org/integration/autoland/rev/c3bdf070cef7
Make `IMContextWrapper::OnCommitCompositionNative` use `eKeyDown` event if DOM `Ctrl`, `Alt` or `Meta` is pressed and the commit string is the same as the key r=m_kato

Comment 10

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/c3bdf070cef7

Comment 11

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:masayuki, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox156 to wontfix.

For more information, please visit BugBot documentation.

Comment 12

[Alexander]

:masayuki, thanks, I confirm that the nightly you sent the link to above works for me.

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Makoto, can you please take care of uplifting this to beta, while Masayuki is away, if that also makes sense to you? Thank you.

Comment 14

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: When using Firefox on Linux, there is some regressions after Firefox 155.
• Some modifier keys for short cut are broken
• If input method is XIM, user cannot input composing text.
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: This issue is a regression by bug 2051354.

This fix to handle modifier key correctly after broken by bug 2051354. Also, when inputting a text as composing text, we set correct value to the UIEvent and dispatch correct composing events.

• String changes made/needed?: No
• Is Android affected?: no

Comment 15

[Makoto Kato [:m_kato]]

Attachment: Bug 2069698 - Make `IMContextWrapper::OnCommitCompositionNative` use `eKeyDown` event if DOM `Ctrl`, `Alt` or `Meta` is pressed and the commit string is the same as the key

IME may send commit signal without the composing state when
user presses Super or something. Then, if the commit string is the
same as the character introduced by the key press, the user may want
to use a shortcut key or an access key. Therefore, we need to dispatch
eKeyDown instead of composition events or a content event with
Process eKeyDown since the global key handler needs to handle the
key event as a shortcut key.

Original Revision: https://phabricator.services.mozilla.com/D323946

Comment 16

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/d6029c373278
https://hg.mozilla.org/releases/mozilla-beta/rev/e3ebac2f870d

Comment 18

[Negritas Sergiu, Desktop QA]

Hello! I have tried to verify the fix in firefox 156.0b6 on Ubuntu 24.04 on wayland and after modifying the ui.key.accelKey to 91 the Super+a/c/v does not select the text or copy or paste. However the Super+t/w opens and closes a new tab. If the ui.key.accelKey is left by default the super+t/w does nothing.

Is this the expected outcome of the key press since i'm not sure since I can't fully reproduce the issue and can't verify the fix if the keypress for Super+a/c/v does not select all/copy/paste.

Have a nice day!

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, the editing command shortcut keys are considered without ui.key.accelKey to align the shortcut keys to the native controls. Therefore, it may happen.

Comment 20

[Negritas Sergiu, Desktop QA]

Hello! Thank you for the clarifications I rechecked with firefox 157.0a1(2026-09-10) and 156.0b6 the issue is fixed.

I will update the status and flags of this issue.

Have a nice day!