1542228 - Urlbar search recommendations dropdown/popup/panel blinks/flickers whenever I type with Korean IME

Status: REOPENED

(Firefox :: Address Bar, defect, P3)

Description

[Lee Jeonghyun]

Attachment: 화면 기록 2019-04-05 오후 10.00.44.mov

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Type korean letters on address bar.

Actual results:

Search recommendations dropdown blinks whenever I type in korean, English doesn't.

Expected results:

Search recommendations dropdown should not blink no matter what language I type.

Comment 1

[:Gijs (he/him)]

Again, not sure why this got moved... Seems specific to the search bar.

Reporter: does the same thing happen in the location/address bar?

Comment 2

[Dale Harvey (:daleharvey)]

Sorry new to triage here, I thought the Search component mostly refererred to the backend / SearchService and the UI would come under toolbars, please move the stuff back if I get it wrong and will figure out where the boundary is, cheers

Comment 3

[Lee Jeonghyun]

(In reply to :Gijs (he/him) from comment #1)

Again, not sure why this got moved... Seems specific to the search bar.

Reporter: does the same thing happen in the location/address bar?

The thing what I reported happens in the address bar.

Comment 4

[Dale Harvey (:daleharvey)]

Given it happens in the address bar, sounds like toolbar is the best place for this one hopefully

Comment 5

[:Gijs (he/him)]

(In reply to Dale Harvey (:daleharvey) from comment #4)

Given it happens in the address bar, sounds like toolbar is the best place for this one hopefully

No, there's a separate component for the location/address/url bar component and its autocomplete popup...

Comment 6

[Drew Willcoxon :adw]

subacc09, thanks for reporting this. I can't reproduce your video exactly where it looks like you're simply hitting the space bar over and over to trigger the problem, but I do notice that as I type random keys with macOS's Korean IME, the popup flickers, and it doesn't flicker when I type in English. (With the space key, the flicker happens when I hit space one time, but not after that.)

Would you mind downloading the Firefox Nightly and trying to reproduce the problem there? https://www.mozilla.org/en-US/firefox/channel/desktop/ (That's a U.S. English link -- just search for Firefox Nightly if it doesn't redirect to your locale)

Be sure to create a new Firefox profile to test with Nightly. Once you're running Nightly, please go to about:config, search for browser.urlbar.quantumbar. Its value should be "true". If it's not, press the Toggle button.

I can reproduce the problem on Nightly, but I'd like to make sure that you can, too.

Comment 7

[Lee Jeonghyun]

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

subacc09, thanks for reporting this. I can't reproduce your video exactly where it looks like you're simply hitting the space bar over and over to trigger the problem, but I do notice that as I type random keys with macOS's Korean IME, the popup flickers, and it doesn't flicker when I type in English. (With the space key, the flicker happens when I hit space one time, but not after that.)

Would you mind downloading the Firefox Nightly and trying to reproduce the problem there? https://www.mozilla.org/en-US/firefox/channel/desktop/ (That's a U.S. English link -- just search for Firefox Nightly if it doesn't redirect to your locale)

Be sure to create a new Firefox profile to test with Nightly. Once you're running Nightly, please go to about:config, search for browser.urlbar.quantumbar. Its value should be "true". If it's not, press the Toggle button.

I can reproduce the problem on Nightly, but I'd like to make sure that you can, too.

I can reproduce it either. Nightly version, and browser.urlbar.quantumbar toggled true.

Comment 8

[Drew Willcoxon :adw]

Thanks! I'm guessing this has to do with how we handle IME composition. We should fix this for release. It would be good to know whether this happens only on Mac.

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Why is it a qb release blocker if it also happens in 66?

Comment 10

[Drew Willcoxon :adw]

True

Comment 11

[Lee Jeonghyun]

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

Thanks! I'm guessing this has to do with how we handle IME composition. We should fix this for release. It would be good to know whether this happens only on Mac.

Yup. I can't reproduce on Windows. Don't know how it's gonna be on Linux.

Comment 12

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

It sounds annoying, but it's not a P1, for which it would need an assignee at least.

Comment 13

[Drew Willcoxon :adw]

Tweaking the summary to make it easier to find in searches

Comment 14

[Florencia Di Ciocco, NI to vbalducci]

Hi, I think that this bug has been fixed. If I'm mistaken, please reopen it.
Regards, Flor.

Comment 15

[Lee Jeonghyun]

[Tracking Requested - why for this release]:

Comment 16

[:Gijs (he/him)]

Masatoshi, are you in a position to advise on what is going on here or how to fix it?

Comment 17

[Masatoshi Kimura [:emk]]

Masayuki would be a better person about IME problems.

Comment 18

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Since this is about Korean IME, you could try setting the experimental pref browser.urlbar.imeCompositionClosesPanel to false, that will keep the urlbar panel open.

Comment 19

[Lee Jeonghyun]

Since this is about Korean IME, you could try setting the experimental pref browser.urlbar.imeCompositionClosesPanel to false, that will keep the urlbar panel open.

The issue stays the same even if the config set to false

Comment 20

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

which version of Firefox are you using?

Comment 21

[Lee Jeonghyun]

I'm using 92.0

Comment 22

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Kagami, do you see the same, can you help us understanding what's up?

Comment 23

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

I think the pref is now browser.urlbar.keepPanelOpenDuringImeComposition=true. Could you try do that?

Comment 24

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Thank you, you're right the pref was renamed, sorry for pointing out the wrong pref :(

Comment 25

[Lee Jeonghyun]

I think the pref is now browser.urlbar.keepPanelOpenDuringImeComposition=true. Could you try do that?

The issue is gone after I set to this. Thanks for the catch up :)

Comment 26

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

Cool!

Marco, is there a plan to take the experiment further? Can we set it as default for ko-KR (if such configuration is even supported)?

Comment 27

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

The long term plan was bug 1680801, but it seems complex and requires changes to the ime API, maybe it's not even feasible (it sounds like we can't know if IME will open a picker or not).
I don't know enough about korean language and keyboard layouts to tell whether this would be a good change for all of them, or only a subset of them. If we can clearly identify and detect keyboard layouts where this is an obvious improvement, we should enable it for those.

Comment 28

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

I'm sure 99.9% of users on Windows just use Microsoft Korean IME, and also sure third-parties are trying hard to mock its (undocumented 😬) behavior, so it's generally safe to think only about that single implementation.

I believe this is an obvious improvement for Microsoft Korean IME, but objections are welcome.

Comment 29

[:Gijs (he/him)]

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

I'm sure 99.9% of users on Windows just use Microsoft Korean IME, and also sure third-parties are trying hard to mock its (undocumented 😬) behavior, so it's generally safe to think only about that single implementation.

What user group is this 99.9% talking about? It's implicit in your message, unfortunately, and it sounds to me like in comment #27 Marco is suggesting that we're fine enabling this behaviour for the right user set, but the important question is how to identify that user set. Easy ways of doing that are based on the Firefox locale, or perhaps the Windows locale, or less certainly, the keyboard configuration. Do we expose the IME in use and/or keyboard layout somewhere that the URL bar frontend code can easily figure out? Or do you think using the Windows or Firefox locale is a good enough proxy? It's not really clear to me which of these you're suggesting we do.

Comment 30

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

My background was comment #26, the users on Firefox ko-KR locale. Since behaviors of Korean keyboards on Windows are same or at least similar in terms of picker opening (they open it only from dedicated Hanja conversion key, which happens rarely enough), I think it's okay to enable it for all Korean users.

Ideally it would be better to detect keybord config but I have no idea about that, maybe Masayuki is better person for that (and he's already NI'ed).

Comment 31

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

Some more background for the decision:

• The IME market for Korean language is not big, mostly because Hangul is mostly written as-is and rarely needs conversion to Hanja (which opens the picker), whereas writing Japanese does the conversion very frequently. (AFAIK third party Japanese IMEs are mostly for better conversion feature)
• How rare is that? If you open https://newsstand.naver.com/ and click random articles written in Korean and you'll typically see zero Hanja.

Comment 32

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

Well, I'm in PTO so I'll be back here next week though.

Currently, no way to know the active keyboard layout is for which language nor whether IME or not from JS. We could do it at least on Windows and macOS with some patches.

And we're collecting share of IMEs in our users who use IME at least once in a session:

• Windows
• macOS

Download the data, and calculate the share only from Korean IMEs. Note that same IME are collected as different IME on Windows if the name is different in some locales of OS.

Comment 33

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

On Windows, Korean IME share in our beta 92 users is:

• MICROSOFT 입력기 (MICROSOFT IME): 91.7%
• MICROSOFT IME 2010: 3.2%
• MICROSOFT OFFICE IME 2007: 2.5%

And those IMEs are < 1%:

• 한컴 입력기
• 微软输入法 (Microsoft IME on zh-CN?)
• 微軟輸入法 (Microsoft IME on zh-TW?)
• NALGAESET HANGUL INPUT SYSTEM
• 날개셋 한글 입력기
• 윤디 한글 입력기
• MICROSOFT OLD HANGUL
• ÉDITEUR DE MÉTHODE D’ENTRÉE MICROSOFT
• MICROSOFT-IME
• <날개셋> 한글 입력기
• EDYTOR IME FIRMY MICROSOFT
• MICROSOFT 옛한글

On macOS:

• COM.APPLE.INPUTMETHOD.KOREAN.2SETKOREAN: 95%
• ORG.YOUKNOWONE.INPUTMETHOD.GUREUM.HAN2: 1.6%
• ORG.YOUKNOWONE.INPUTMETHOD.GUREUM.HAN3FINAL: 1.3%

And those IMEs are < 1%:

• COM.APPLE.INPUTMETHOD.KOREAN.390SEBULSHIK
• COM.APPLE.INPUTMETHOD.KOREAN.3SETKOREAN
• COM.APPLE.INPUTMETHOD.KOREAN.HNCROMAJA

But especially on macOS, the number of users who use Korean IME is not so many. So the low-share IME's percentage can be different from actual share.