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

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, enhancement, P3)

Description

[Makoto Kato [:m_kato]]

(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.

Comment 1

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

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.

Comment 2

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

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

[Drew Willcoxon :adw]

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?

Comment 4

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

(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.

Comment 5

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

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.

Comment 6

[Drew Willcoxon :adw]

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.

Comment 7

[Daisuke Akatsuka (:daisuke)]

As it takes a long time since filing this bug, I investigated behaviors with Alt+Enter on multiple OS and browsers.

OS	Browser	IME	Behavior while composition	Behavior after committing composition	Key while composition	Key after committing composition
OSX 12	Nightly	Default	Nothing	Show the content in new tab	isComposing: true / key: “Process” / keyCode: 229 / code: “Enter”	isComposing: false / key: “Enter” / keyCode: 13 / code: “Enter”
		ATOK	Nothing	Show the content in new tab	isComposing: true / key: “Process” / keyCode: 229 / code: “Enter”	isComposing: false / key: “Enter” / keyCode: 13 / code: “Enter”
		Google	Nothing	Show the content in new tab	isComposing: true / key: “Process” / keyCode: 229 / code: “Enter”	isComposing: false / key: “Enter” / keyCode: 13 / code: “Enter”
	Canary	Default	Nothing	Show the content in new tab
	Safari	Default	Show the content in new tab	Show the content in new tab
Windows 11	Nightly	Default	Show the content in new tab	Show the content in new tab	isComposing: true / key: “Enter” / keyCode: 13 / code: “Enter”	isComposing: false / key: “Enter” / keyCode: 13 / code: “Enter”
		ATOK	Show the content in new tab	Show the content in new tab	isComposing: true / key: “Enter” / keyCode: 13 / code: “Enter”	isComposing: false / key: “Enter” / keyCode: 13 / code: “Enter”
	Edge	Default	Show the content in new tab	Show the content in new tab
	Canary	Default	Show the content in new tab	Show the content in new tab
Ubuntu 20	Nightly	Default	Nothing	Show the content in new tab	isComposing: true / key: “Process” / keyCode: 229 / code: “Enter”	isComposing: false / key: “Enter” / keyCode: 13 / code: “Enter”

From this result, it seems that there are no differences by IME, but are different dependent on OS or browsers.
Then, look at the behavior for browsers, all browsers are the same on Windows 11, but not OSX.
Considering the behavior for the original default browser (Safari on OSX, Edge on Win) and consistency for our Firefox, as the first report suggested, we’d better open the content in a new tab even during composition, I thought. But, I’d like to hear your opinion, Drew, Masayuki, and Makoto.

And also, to find a way to realize this, I investigated the key event upon Alt+Enter on _on_keydown on UrlbarInput.jsm.
From the result, the keyCode is 229 on OSX and Ubuntu even Alt+Enter while composition. UrlbarController handles only when KeyEvent.keyCode === DOM_VK_RETURN, the current behavior (no action) convinces me.
So, I tried to make KeyEvent.code === “Enter” proceed with the process as same as DOM_VK_RETURN, it could open the content in a new tab even while composition as expected. But, as I’m not sure whether or not we can use KeyEvent.code to decide the key kind, I’d like to ask Masayuki-san.

Comment 8

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

It's wrong to refer KeyboardEvent.code for the purpose (in strictly speaking). For example, user may swap Enter key and something another key. Therefore, KeyboardEvent.key is the most preferred way to check the users' intention.

On the other hand, if and only if we can be sure that the Enter key is not handled by IME, we can stop dispatching keydown event as "Process" key because Chrome exposes "Enter" when I press Alt+Enter.

Comment 9

[Daisuke Akatsuka (:daisuke)]

Thank you for your replying!

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #8)

It's wrong to refer KeyboardEvent.code for the purpose (in strictly speaking). For example, user may swap Enter key and something another key. Therefore, KeyboardEvent.key is the most preferred way to check the users' intention.

I see, thanks!

On the other hand, if and only if we can be sure that the Enter key is not handled by IME, we can stop dispatching keydown event as "Process" key because Chrome exposes "Enter" when I press Alt+Enter.

Oh, this sounds cool!
I'd like to try to fix with that way.

Comment 10

[Drew Willcoxon :adw]

Thanks for doing all this analysis Daisuke. One thing I don't understand though: You found that Alt+Enter on Windows during composition opens a new tab, right? Doesn't that contradict comment 0 and the user's forum post? Judging by their signature, they are using Firefox on Windows. Maybe Firefox's behavior changed since this bug was filed?

Comment 11

[Daisuke Akatsuka (:daisuke)]

(In reply to Drew Willcoxon :adw from comment #10)

One thing I don't understand though: You found that Alt+Enter on Windows during composition opens a new tab, right? Doesn't that contradict comment 0 and the user's forum post? Judging by their signature, they are using Firefox on Windows. Maybe Firefox's behavior changed since this bug was filed?

Thank you very much!
Yeah, I investigated using mozregression, it seems that this behavior was changed between 2019/05/01 - 2019/05/03.
(But, as it seems that mozregression could not get the build image for 2019/05/02, I could not find exact bug)

Comment 12

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

FYI: On Windows, OS/IME let focused application know whether each keydown or keyup event is "processed" by IME or something before the application strictly. Therefore, unless IME consumes the events, widget for Windows dispatches keydown and keyup events as same as there is no composition string if corresponding native event is not "processed".

On the other platforms, OS/IME do not provide obvious information whether each key event is handled by IME. Therefore, widget for the others roundly consider that all keyboard events while there is composition are "processed" by IME (this is compatible behavior with the other browsers).

Therefore, once make our widget consider it stricter, widget can dispatch non-"processed" keyboard events into the web (and chrome). However, it means that we take incompatible behavior with Chrome. Therefore, it might be better to do it only with allowed-list or something.

Comment 13

[Drew Willcoxon :adw]

Then, look at the behavior for browsers, all browsers are the same on Windows 11, but not OSX.
Considering the behavior for the original default browser (Safari on OSX, Edge on Win) and consistency for our Firefox, as the first report suggested, we’d better open the content in a new tab even during composition, I thought. But, I’d like to hear your opinion, Drew, Masayuki, and Makoto.

To summarize, the question is what should we do on Mac, right? And right now, we do nothing while in composition, and your suggestion is to open a new tab like Safari, right?

I don't feel strongly about it, and I don't use an IME every day so I can't draw on personal experience, but I think I disagree. I couldn't find browser usage for macOS, but since Chrome has such an overwhelming usage share across all of desktop, it's probably safe to say most Mac users use Chrome too, not Safari, and for that reason alone we should have a good reason to do something different in this case. Another reason for not changing the behavior is that we may break the habits of users who would end up triggering a new tab when they didn't mean to.

So I think my suggestion is to mark this as worksforme, since the behavior in comment 0 no longer happens on Windows. What do you all think?

Comment 14

[Daisuke Akatsuka (:daisuke)]

Thank you very much for your suggestion!
I see, it may be acceptable if the behavior is similar to Chrome rather. I got it.
As you said, as the original request has been fulfilled, I'll close this.
Let’s think about it again if there are any requests from users.