[Alt] + [Enter] should start search on new tab even if having IME composition string on address bar

NEW
Unassigned

Status

()

enhancement
P3
normal
11 months ago
10 months ago

People

(Reporter: m_kato, Unassigned)

Tracking

({inputmethod, parity-chrome, parity-edge})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox62 affected)

Details

Reporter

Description

11 months ago
(From Japanese community as https://forums.mozillazine.jp/viewtopic.php?f=2&t=17091)

Chrome, Edge and Firefox can start a search on new tab from address bar by [Alt] + [Enter].  But when address bar has IME composing string, behaviour is different.

- Chrome and Edge
Commit composition string then start search on new tab.

- Firefox
no action.

Like Chrome and Edge, we might have to commit string, then start search even if having IME composition string.
As far as I've tested, Enter key event is not consumed by MS-IME, ATOK nor Google Japanese Input. So, if we'd take same behavior, UI should start to handle Enter key press even if its isComposing is true. But we should be careful on Linux because still not stable after committing composition forcibly on Linux.
Ah, on macOS and Linux, we always mark keydown of Enter as "processed by IME". And other browsers do not handle Alt+Enter during composition on non-Windows platform. So, point of this bug is, whether we should use same behavior on Windows or not.

Comment 3

11 months ago
Masayuki, which Firefox components would be responsible for this?  I realize there may be more than one.  I did a quick search through the related front-end files (autocomplete.xml, urlbarBindings.xml) but didn't see anything related to IME handling.  Should this bug be moved somewhere else?
Flags: needinfo?(masayuki)
(In reply to Drew Willcoxon :adw from comment #3)
> Masayuki, which Firefox components would be responsible for this?  I realize
> there may be more than one.  I did a quick search through the related
> front-end files (autocomplete.xml, urlbarBindings.xml) but didn't see
> anything related to IME handling.  Should this bug be moved somewhere else?

I'm still not sure who checks if it's in composition.

There are two ways to check whether a keyboard event is fired during composition, one is checking KeyboardEvent.isComposing, the other is checking a flag which is set to true when compositionstart and false when compositionend. As far as I checked, places and autocomplete check if keyboard event is in composition, but I've not found where is the code handling Alt+Enter.
Flags: needinfo?(masayuki)
Oh, but this depends on bug 354358. Currently, widget does not dispatch keydown nor keyup events during composition in release build. So, this is currently fixable only on Nightly and early Beta.
Depends on: 354358

Comment 6

11 months ago
Ah "composition" is what I should have searched for, thanks.

Alt+Enter is handled here: https://dxr.mozilla.org/mozilla-central/rev/681eb7dfa324dd50403c382888929ea8b8b11b00/browser/base/content/urlbarBindings.xml#698

_whereToOpen returns "tab" in that case: https://dxr.mozilla.org/mozilla-central/rev/681eb7dfa324dd50403c382888929ea8b8b11b00/browser/base/content/urlbarBindings.xml#630

But I guess we don't even get to that point when composing, which is why this bug exists?  In that case, we may need to modify nsAutoCompleteController so that it calls input->OnTextEntered() when composing, at least on Windows: https://dxr.mozilla.org/mozilla-central/rev/681eb7dfa324dd50403c382888929ea8b8b11b00/toolkit/components/autocomplete/nsAutoCompleteController.cpp#1323

I'm not sure how nsAutoCompleteController interacts with composition, so I'm just guessing.  It does seem like the problem can be fixed in autocomplete and/or front-end code.

This seems like an annoying bug for IME users on Windows who are used to the other browsers' behavior, so I'll give this a high-ish priority.
Priority: -- → P2

Updated

10 months ago
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.