1632597 - Typing Hangul and Alt+Enter on the address bar omits the last letter

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Kagami Rosylight [:saschanaz] (they/them) (OOO until Dec 11)]

1. Type '도도' (eheh in QWERTY) on the address bar using Microsoft Korean IME
2. Make sure the composition is not finished yet. Tap Alt+Enter to search in a new tab

Expected: The search query should be '도도'.
Actual: It's '도'.

Comment 1

[Kagami Rosylight [:saschanaz] (they/them) (OOO until Dec 11)]

As this is related to IME, should this also be in "DOM: UI Events & Focus Handling" component?

Comment 2

[Kagami Rosylight [:saschanaz] (they/them) (OOO until Dec 11)]

This is a "better" behavior introduced after Bug 1548031 enabled QuantumBar, as previously Alt+Enter did nothing during composition.

Comment 3

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

(In reply to Kagami :saschanaz from comment #1)

As this is related to IME, should this also be in "DOM: UI Events & Focus Handling" component?

Anything is okay. Probably, QuantumBar does not check KeyboardEvent.isComposing at handling Enter key event.

Comment 4

[Marco Bonardo [:mak]]

we revised IME handling for QB, it's possible this was missed. Patches are welcome, all the code is js now and should be more readable.

Comment 5

[Kagami Rosylight [:saschanaz] (they/them) (OOO until Dec 11)]

I think the fix should be "force-finishing" composition rather than restoring the previous behavior. Is finishing composition doable in JS?

Comment 6

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

Use nsIEditor.forceCompositionEnd() for the purpose.
https://searchfox.org/mozilla-central/rev/41c3ea3ee8eab9ce7b82932257cb80b703cbba67/editor/nsIEditor.idl#483

However, QuantumBar is in the chrome process so that committing composition may cause canceling the composition rather than commit composition as-is. It depends on active IME. Perhaps, getting the latest string before calling the API must be safer. (Note that on Linux, there is no stable API to commit composition, so, please test it on Linux before landing at least on Ubuntu's default settings.)

Comment 7

[Kagami Rosylight [:saschanaz] (they/them) (OOO until Dec 11)]

Attachment: Bug 1632597 - Show search suggestion while composition

Currently Firefox does not show search suggestion while composing CJK characters, deviating from Edge/Chrome behavior. This behavior causes two problems: 1) users always have to finish composition first to see the most relevant suggestions and 2) searching by Alt+Enter during composition uses outdated search query. This patch fixes those unexpected behaviors by showing suggestions during composition.

Comment 8

[Marco Bonardo [:mak]]

Testing with Corean IME everything is fine, but testing Japanise IME this has a visual downside. The difference is whether we show the IME picker panel; it will appear on top of the results panel, pretty much covering results, and making them unusable. That by itself doesn't break the urlbar, but it looks quite bad.
Showing unusable results is not better than not showing them, and the browser looks broken.

Comparing the behavior with Chrome/Edge, they don't show an IME picker panel by default, they just show results and an underline of the current IME compositing token, then you can press TAB to show the IME panel (if there are picks, otherwise it just moves to the next urlbar result... This looks sub-optimal yet, because it's not predictable, they underline the token regardless). As soon as you pick something in the IME panel, the urlbar results pane go away, likely because showing 2 panels on top looks ugly.

Either we implement something similar, or we need a solution to close the panel only if the picker opens (will likely still be broken if the picker opens), or we force composition on Enter.

Based on this, the proposed solution looks incomplete, because it fixes the original problem but it introduces a visual bug in other IME layouts.

I'm not an IME expert, thus I'll ask masayuki-san to evaluate this case.

1. What's the difference between Corean and Japanese IME, why is one showing a picker but not the other one
2. How can we detect those cases, is it possible to know is an IME picker can be opened or not? If there's no ime picker we could surely continue normally showing results...
3. How do you suggest we move this forward? should we revise our IME handling to act more like Chrome, or do you have alternative ideas?

Comment 9

[Kagami Rosylight [:saschanaz] (they/them) (OOO until Dec 11)]

it will appear on top of the results panel, pretty much covering results, and making them unusable.

This is what Google does on their search engine, so I guess it's not completely unexpected. But yes, probably better to follow others, there should be a public API to do this.

What's the difference between Corean and Japanese IME, why is one showing a picker but not the other one

The picker in Korean IME only opens when you tap the left Alt key, as Koreans don't frequently use Hanja conversion.

Comment 10

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

(In reply to Marco Bonardo [:mak] from comment #8)

Testing with Corean IME everything is fine, but testing Japanise IME this has a visual downside. The difference is whether we show the IME picker panel; it will appear on top of the results panel, pretty much covering results, and making them unusable. That by itself doesn't break the urlbar, but it looks quite bad.

Yes, that's why browser and toolkit hides Gecko's popup window during IME composition.

Showing unusable results is not better than not showing them, and the browser looks broken.

Yes, unfortunately.

Comparing the behavior with Chrome/Edge, they don't show an IME picker panel by default, they just show results and an underline of the current IME compositing token, then you can press TAB to show the IME panel (if there are picks, otherwise it just moves to the next urlbar result... This looks sub-optimal yet, because it's not predictable, they underline the token regardless).

Hmm, our IME handler does nothing special. IME sometimes switch their behavior with active window's class name etc.

As soon as you pick something in the IME panel, the urlbar results pane go away, likely because showing 2 panels on top looks ugly.

Yeah, and if user wants to see the covered UI, it becomes an a11y issue.

Either we implement something similar, or we need a solution to close the panel only if the picker opens (will likely still be broken if the picker opens), or we force composition on Enter.

As far as I know, we cannot detect whether IME opens their own popup on Windows, macOS and GTK or not without scanning windows.

Based on this, the proposed solution looks incomplete, because it fixes the original problem but it introduces a visual bug in other IME layouts.

I'm not an IME expert, thus I'll ask masayuki-san to evaluate this case.

1. What's the difference between Corean and Japanese IME, why is one showing a picker but not the other one
2. How can we detect those cases, is it possible to know is an IME picker can be opened or not? If there's no ime picker we could surely continue normally showing results...
3. How do you suggest we move this forward? should we revise our IME handling to act more like Chrome, or do you have alternative ideas?

Possible simple approach is, making an API to get active IME's language, and make popups behave differently whether the active keyboard layout is IME for CJT or the others (although Win10 tries to create IME for Western languages for suggesting typing words). But in this bug, I believe that only the reported issue should be fixed.

Comment 11

[Marco Bonardo [:mak]]

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

Comparing the behavior with Chrome/Edge, they don't show an IME picker panel by default, they just show results and an underline of the current IME compositing token, then you can press TAB to show the IME panel (if there are picks, otherwise it just moves to the next urlbar result... This looks sub-optimal yet, because it's not predictable, they underline the token regardless).

Hmm, our IME handler does nothing special. IME sometimes switch their behavior with active window's class name etc.

Not sure who is doing that, but our behavior is quite different from Chrome/Edge. Maybe that should be investigated.

Possible simple approach is, making an API to get active IME's language, and make popups behave differently whether the active keyboard layout is IME for CJT or the others (although Win10 tries to create IME for Western languages for suggesting typing words). But in this bug, I believe that only the reported issue should be fixed.

I suppose you mean with a different approach, since showing both popups doesn't sound like a promising idea.

Comment 12

[Marco Bonardo [:mak]]

Did Bug 1673669 fix this? It worked for me locally, but I'd love to get your confirmation

Comment 13

[Kagami Rosylight [:saschanaz] (they/them) (OOO until Dec 11)]

Yes, this is fixed, thanks! 🎉