2084459 - [GTK] Address bar reports free-form input purpose instead of URL (mozAwesomebar not mapped)

Status: NEW

(Core :: Widget: Gtk, defect)

Description

[Nguyen Phi]

Input methods that commit each letter at once and fix a word with Backspace and a new commit (Vietnamese ones such as Ngó Sen) need to know a field autocompletes inline, because their Backspace removes the selected completion first. Ngó Sen typed "mowf" (Telex for "mờ") as "moờ" in the address bar until it added a check on the program name: https://github.com/ngosen/ngosen/issues/161

Firefox 157.0.1, CachyOS, KDE Plasma 6.7 Wayland (KWin), fresh profile, text-input-v3, no GTK_IM_MODULE.

Steps:

1. Run Firefox with WAYLAND_DEBUG=client.
2. Open a page with <input type="url"> and <input inputmode="url">.
3. Focus each field, then press Ctrl+L.

Actual zwp_text_input_v3 requests (purpose 5 = url):

type=url:      set_content_type(0, 5)
inputmode=url: set_content_type(0, 5)
address bar:   set_content_type(0, 0)

Expected: the address bar reports the URL purpose too.

UrlbarInputBase.mjs sets inputMode to "mozAwesomebar". IMContextWrapper::SetInputPurposeAndInputHints has no case for it and leaves GTK_INPUT_PURPOSE_FREE_FORM. Windows (IMEHandler::AppendInputScopeFromInputMode) and GeckoView map it to URL; mapping it to GTK_INPUT_PURPOSE_URL would match them.

Not tested: X11, GNOME, or whether any Linux input method closes itself on the URL purpose, the reason Windows skips IS_URL for some IMEs.

Assisted-by: AI

Comment 1

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

Well, we need to make IMContextWrapper::SetInputPurposeAndInputHints handle mozAwesomebar value explicitly like IMEHandler::AppendInputScopeFromInputMode, but we need to be careful about the multi-purpose of the address bar since it's also a form for web and some local data (like history, bookmark, etc) search. So, specializing for URL may make worse UX for some IME or VKB users if the IME/VKB is optimized to input URL too much.

I don't have much time to work on this and we need to investigate whether it's better to switch the behavior of address bar for the major environment users.

Comment 2

[Nguyen Phi]

I measured what Linux input methods and on-screen keyboards do with the URL purpose, using Firefox's own <input type="url"> next to <input type="text"> on one page. Keys were sent with virsh send-key and the values read from the page's input events.

Input methods: the same keys gave the same text in both fields. [bảng 9 bộ gõ, 2 cột text/url: tiếng việt · にほんご · 你好 · 한글]

None switched to direct input or changed mode. The purpose did reach the engines: fcitx5's DebugInfo shows the Url capability on the url field and not on the text field.

On-screen keyboards: GNOME Shell 50 keyboard only swaps the bottom row (emoji key → www., :, /); letter rows and the active IBus engine stay the same. Plasma 6.8 virtual keyboard: identical layout for both fields.
For comparison: Chromium 154 with --enable-wayland-ime already reports the URL purpose for its omnibox; GNOME Web 51 reports free-form.
Not tested: X11 sessions, GTK's own input method on URL fields, other on-screen keyboards (Maliit, squeekboard).

So on Linux the engines ignore the purpose and the two desktop keyboards only adjust punctuation keys, which is what Windows and Android users already get. I can prepare the patch for SetInputPurposeAndInputHints if that helps.

Assisted-by: AI