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

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.

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.

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.

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?

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

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.

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?

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.