1629250 - Hangul composition doesn't render after opening browser menu by alt key

Status: RESOLVED DUPLICATE of bug 1629347

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: Repro video

1. Type Hangul on any webpage
2. Press Alt to open the broswer menu
3. Press Alt again to close it
4. Type Hangul again

Expected: It should show composition process
Actual: No visual composition process

This is a regression from build 2019-04-01 and happens with and without Fission. Too bad it's older than a year and thus can't be bisected by mozregression.

Comment 1

[Kagami Rosylight [:saschanaz] (they/them)]

This can't be reproduced on Ubuntu via WSL. Mirko, could you confirm?

Also, is there a good way to bisect an old bug? Local build doesn't work (Bug 1629305) nor CI (Bug 1629298), should I just forget about bisection?

Comment 2

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

I have little experience with Hangul and composed characters, but tried the following on Ubuntu 18.04:

1. Switch input mode to Hangul.
2. On a US keyboard press "aoaoao".
3. Press "Alt" button twice.
4. Press "aoao"

Result: there are five composed characters, each one looking similar to 'oH'. So I guess, this works.

Please let me know if the above doesn't make sense and provide more exact steps to reproduce this.

Doesn't mozregression support older builds too? I don't remember such a restriction.

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

Thanks, that says this is Windows only issue. Not sure this should be in focus handling component then, what do you think Masayuki?

Doesn't mozregression support older builds too? I don't remember such a restriction.

Mozregression does support old Nightly builds but it can't bisect in commit level, as taskcluster removes mozilla-central builds older than a year.

Comment 4

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

Not sure this should be in focus handling component then, what do you think Masayuki?

All IME/keyboard related bugs should be in "DOM: UI Events & Focus Handling" even the bug is in another module's code because input event handling is too important for users and guessing where is the buggy requires a lot of investigation.

BTW, when Alt key activates our XUL menubar, composition should be committed forcibly in the previously focused editor because menubar needs to handle all key events to perform mnemonic, but native IME does not have a way to suspend their composition temporarily (I don't mean that it's impossible), and anyway even if we do it, some menu may change focus. Therefore, keeping composition makes harder to maintain the composition. Or, another approach is, preventing Alt key handling in XUL menubar when there is a composition (probably, WidgetKeyboardEvent::mIsComposing can be used for this check) may be simpler. But I'm not sure that Korean language users like which behavior better.

Comment 5

[Kagami Rosylight [:saschanaz] (they/them)]

but native IME does not have a way to suspend their composition temporarily (I don't mean that it's impossible)

Apps like Notepad does suspend the composition but not temporarily. It does not restore composition state after escaping the menu, and I think this is the preferred behavior.

Comment 6

[Cristian Fogel [:cfogel]]

Based on the initial report, the best regression range would be: link.

As far as trying to get something more accurate, noticed some differences up that might be relevant or not,
Left ALT - open/closes menu;
Right ALT - toggles the input.

Other than that, oddly enough the compositor seemed to work even on recent nightly build(s); this being the case for Win10 (18362.719) in case the issue would be linked to the Windows OS version in any way.

Comment 7

[Kagami Rosylight [:saschanaz] (they/them)]

Mozregression says this is fixed in bug 1629347. Thanks Masayuki! 👍