2004150 - Dead Keys composition (e.g., ' + vowel) fails and characters disappear in specific web input fields (e.g., WhatsApp Web, Copilot)

Status: UNCONFIRMED

(Core :: DOM: Editor, defect, P3)

Description

[AbelRMR]

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

Steps to reproduce:

OS: Endeavour OS
Desktop Environment: Wayland Plama
Keyboard Layout: Spanish / Galician (with dead keys)
Hardware: Intel i5 11th Gen, Gigabyte B560M DS3H

2. Detailed Steps to Reproduce:
   Ensure Firefox is running in native Wayland mode (e.g., via MOZ_ENABLE_WAYLAND=1).
   Navigate to a known problematic input field (e.g., the chat box in WhatsApp Web, the input area in Copilot, or any rich text editor on a specific website, but not others like Gemini or this one).
   Attempt to start the writing with an accented character using the Dead Key sequence:
   Press the accent key (e.g., ´ or ').
   Press a vowel (e.g., a, e, i).

Actual results:

Both characters disappear. The Dead Key (') appears briefly (or not at all), and when the vowel (a) is pressed, the entire composition is discarded, resulting in an empty input field where the composed character should be.

Expected results:

á é í ó ú....
Additional info:
This issue does not occur in standard, simple text fields (e.g., this conversation box in Gemini or the Firefox URL bar). It appears to be a conflict with how specific JavaScript-heavy or custom input widgets handle composition events.
The following common workarounds were attempted without success:

    Forcing the use of the simple GTK IM (GTK_IM_MODULE=gtk-im-context-simple).
    Disabling the IM entirely (GTK_IM_MODULE=).
    Forcing Wayland protocol usage (GTK_IM_MODULE=wayland).
    Changing the internal Firefox preference (dom.keyboardevent.dispatch_during_composition to false).
    Forcing the use of the Qt input backend (QT_IM_MODULE=platforminputcontext).

The persistence of the bug after these attempts suggests a deeper issue in the Wayland/GTK integration layer or how Firefox interacts with the composition events during the initial keypress sequence on certain web elements.

Comment 1

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

You can log the keys and how it's processed, run on terminal with MOZ_LOG=KeyboardHandler:4,sync env variable.

Comment 2

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Also is that Wayland only issue?

Comment 3

[AbelRMR]

Attachment: Keyboard log

this log records a failed attempt of typing á, é, í, ó, ú in the text boxes of Copilot (and a successful aà) and Whatsapp. Thank You!

Comment 4

[AbelRMR]

it is the only issue, as far as I know.

Comment 5

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Do I understand correctly that you see the failed keys on particular input elements only? i.e. it works on URL bar for instance but fails on some web sites?

Comment 6

[AbelRMR]

You do, it works properly on the url bar or on some text boxes like this one or Gemini's but not in others like Whatsapp's or Copilot's.
In fact works fine on Copilot's url https://copilot.microsoft.com/ but doesn't on the Office 365 version on https://m365.cloud.microsoft/chat/?auth=2
Does it make any sense?

Comment 7

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Do you see it with MOZ_ENABLE_WAYLAND=0? i.e. running with X11?

Comment 8

[AbelRMR]

yes, I tried to run it with "Exec=env MOZ_ENABLE_WAYLAND=0 firefox" and the issue persists.

Comment 9

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Thanks for testing.

Comment 10

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Not sure what's that - perhaps web compat or input events?

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Masayuki, does this ring any bells
(and really sorry, yet another needinfo)

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 6/26-6/30))]

I have a question, is this bug fixed with adding the domain of the web apps to editor.htmleditor.inputevent.hack.no_dispatch_after_compositionend.addl or editor.htmleditor.inputevent.hack.no_dispatch_before_compositionend.addl from about:config? (These prefs are available in beta or nightly builds for now)

Comment 13

[Agustín [:snowyyd]]

Attachment: Firefox: IBus Wayland (KDE)

Comment 14

[Agustín [:snowyyd]]

I recently discussed this behavior in Fedora Discussion: https://discussion.fedoraproject.org/t/dead-key-input-fails-on-first-character-on-firefox/183565

Test case: https://discussion.fedoraproject.org/t/dead-key-input-fails-on-first-character-on-firefox/183565/4

With the following environment:

• OS: Fedora Linux 44
• Desktop Environment: KDE Plasma 6.6.3
• Display Server: Wayland
• Window Manager: KWin

While I cannot reproduce the exact issue (i.e. the input "disappearing") in the linked test case, I see some inconsistencies in the tests I performed both with IBus and Plasma Keyboard as input methods.

I'm able to reproduce this issue with Plasma Keyboard as the input method. IBus works fine.

Test script:

<!DOCTYPE html>
<html>

<body>
	<textarea id="k" rows="6" cols="60"></textarea>
	<br />
	<button id="dump">Dump</button>

	<script>
		const events = [];

		function snapshot(event)
		{
			const el = event.target;
			const e = {
				type: event.type,
				key: event.key,
				code: event.code,
				which: event.which,
				keyCode: event.keyCode,
				charCode: event.charCode,
				data: event.data ?? null,
				inputType: event.inputType ?? null,
				composed: event.composed,
				isComposing: event.isComposing,
				value: el?.value ?? null,
				selectionStart: el?.selectionStart ?? null,
				selectionEnd: el?.selectionEnd ?? null,
			};

			console.log(e);
			events.push(e);
		}

		const k = document.getElementById('k');
		k.value = '';

		['keydown', 'keypress', 'keyup', 'beforeinput', 'input', 'change', 'compositionstart', 'compositionupdate', 'compositionend']
			.forEach((type) => k.addEventListener(type, snapshot));

		k.focus();

		document.getElementById('dump').addEventListener('click', () => console.log(JSON.stringify(events, null, 2)));
	</script>
</body>

</html>

I tried to upload my tests results as attachments but looks like It's not possible to upload all of them at once. All the results are available in linked issue.

Comment 15

[luigiorombelli]

Attachment: entertrained_bug.mkv

Hi, I can confirm that I’m seeing this bug as well.

I uploaded a video showing the issue on Entertrained with the international keyboard, by comparison it works correctly for example in the terminal.

I can also reproduce it on WhatsApp Web, although there it only affects the first character, not the following ones.

Environment:

• Firefox 149.0
• Arch Linux
• Hyprland 0.54.3
• Wayland session
• LANG=en_US.UTF-8
• kb_layout us
• kb_variant intl

Thanks.