1673669 - When searching by urlbar in Korean, last word is ignored when length of last word is even

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Jun]

Attachment: bugreport.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

While using Korean IME, the last character is highlighted with blue or white background to notify that more vowels or consonants might be combined with this letter. The error occurs when typing search query word with Korean in urlbar while last word highlighted, pressing enter. It only happens on narrow condition. The condition can be reproduced only when:
0) As described, the last word should be highlighted by Korean IME. Copy & paste Korean words does not reproduce the bug.

1. The search query word should include space
   ex) "한국어위키"(X), "한국어 위키"(O)
   "한국서버"(X), "한국 서버"(O)

2. The last word's length of the search query should be even. Words in odd length seems to have no problem so far.
   ex) "한국어 파이썬"(X), "한국어 자바스크립트"(O)

3. The last word does not require to be in combined form. Typing only ㅁ or ㅏ or anything can reproduce it.
   ex) "ㅁㄴㅇㄹ ㅇㅇㅇㅇ"(O), "ㅁㅁㅁㅁ ㅁㅁ"(O)

Actual results:

The highlighted word is ignored, and the the query word is sent without the last letter.
ex) "한국어 위키" -> "한국어 위"
"자바스크립트 강좌" -> "자바스크립트 강"
"파이썬 알고리즘" -> "파이썬 알고리"
"ㅁㄴㅇㄹ ㅇㅇㅇㅇ" -> "ㅁㄴㅇㄹ ㅇㅇㅇ"
"ㅁㅁㅁㅁ ㅁㅁ" -> "ㅁㅁㅁㅁ ㅁ"

The symptom also occurs whatever language is located before.
"javascript 구문" -> "javascript 구"

Expected results:

The search query should be sent with highlighted last word

Comment 1

[Jun]

• The word "ommitted" in the picture is typo. It should be "omitted"

Comment 2

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: space .webm

HI,

I'm attempting to reproduce this bug (I used 4 and 5 characters, to check both odds and even as mentioned in bug's description), I added a space as well, and there's another word in a different language at the beginning, but I cannot seem to reproduce

Please see my attached video and let me know if I'm missing any step.
Setting a component for this in order to get the dev team involved.
(If the team feels it's an incorrect one please feel free to change it to a more appropriate one.)

Best regards,
Clara

Comment 3

[Jun]

TL;DR: Dragging would highlight the word but it is different from what the report was meant to say. Typing is required to reproduce it.

https://filestore.community.support.microsoft.com/api/images/47e6c616-794d-4ba9-8059-94fdc163432e?upload=true

Thank you for replying my first and amateur bug report in Bugzilla. I think I should make the word 'highlighted' more specific.
It was not the dragged part I wished to describe. One Korean character requires one or more vowels and consonants to be assembled, so IME puts the color in the last character to tell user that more can be combined.
The link above is the gif file to show the example of how korean words are typed. The blue box at the last is what I meant to put my finger on it.

To reproduce, it is required to use Korean IME and actually type characters.

To find out if there is someone with the same issue. I posted an article of this issue in KR community. most of people who were using FF stable version replied that they haven't experienced this, but one who were using FF developer edition 83.0 found the same issue were reproduced.

This is the end of my additional comment. I wish this report would make the issue more clear.
If my comment is too vague and needs more explanation, please let me know.

Comment 4

[Harry Twyford]

(In reply to dlwnsgml94 from comment #3)

most of people who were using FF stable version replied that they haven't experienced this, but one who were using FF developer edition 83.0 found the same issue were reproduced.

Thank you, this is helpful. Would you be able to run mozregression to find a regression range? Installation instructions are here https://mozilla.github.io/mozregression/quickstart.html. Since this appeared in Firefox 83, you could set the "good" date as 2020-09-20 to narrow the search. If you're not comfortable setting mozregression up, maybe someone else from the Firefox community you mentioned could run it? It sounds like one needs to be comfortable with Korean IME to reproduce this bug.

Comment 5

[Jun]

(In reply to Harry Twyford [:harry] from comment #4)

Thank you, this is helpful. Would you be able to run mozregression to find a regression range?

Thank you for letting me know mozregression. It was really helpful and neat tool to find the issue.
I've done the bisection search and it shows me the message as below.

Bug 1647925 - Make EventBufferer more reliable with tab-to-search. r=adw

Differential Revision: https://phabricator.services.mozilla.com/D92818

2020-11-07T14:11:17.053000: DEBUG : Did not find a branch, checking all integration branches
2020-11-07T14:11:17.069000: INFO : The bisection is done.
2020-11-07T14:11:17.069000: INFO : Stopped

This is only the part which includes the message I considered relevant. If this isn't or more log is required, could you write any comment to notify?

With great thanks
Jun

P.S: Really sorry for the grammatical errors I've made. I wonder if there would be any way to correct this, but I haven't found one.
P.S2: Does mozregression save all the nightly build I've tested? If so, could you tell me where to find them?

Comment 6

[Jun]

(In reply to dlwnsgml94 from comment #5)

This is only the part which includes the message I considered relevant. If this isn't or more log is required, could you write any comment to notify?

I just saved every log as text format. If you wish, I'll upload this as a file.

Comment 7

[Marco Bonardo [:mak]]

It sounds lime we may be missing a composition finalization, though I can't really tell why bug 1647925 would make a difference

Comment 8

[Harry Twyford]

dlwnsgml94, thanks for finding the regression window for this bug! If you're looking for a way to contribute to Firefox in the future, bugs with the keyword regressionwindow-wanted are looking for volunteers to run mozregression.

(In reply to dlwnsgml94 from comment #5)

P.S2: Does mozregression save all the nightly build I've tested? If so, could you tell me where to find them?

mozregression stores its Nightly builds in ~/.mozilla/mozregression/Persist. On Windows that's <user folder>/.mozilla/mozregression/Persist.

Comment 9

[Jim Mathies [:jimm]]

Hey mak, curious how serious you feel this is? Should we track for 83?

Comment 10

[Marco Bonardo [:mak]]

I don't think it's worth tracking, also because I doubt we could have a safe patch in time for 83.
But this is quite annoying for users hitting it, I imagine, so we should investigate it sooner than later. Unfortunately we also have other regressions and priorities we're trying to solve asap.

Comment 11

[Ji Lee]

Still Same in 84b3. When will it be fixed?

Comment 12

[dididi]

Hi. I'm Korean user, too.

I have a same issue.

The address bar doesn't work well.

For example, when I search "가나 다라" at the address bar, the last word "라" is cut off unexpectedly.

This bug is very annoying so I downgraded the Firefox version to 82.0 from 83.0.

There is no same bug in 82.0 version.

Comment 13

[Marco Bonardo [:mak]]

I'll have a look at this. I don't know Korean, but there are examples in the bug that should help me reproducing and figuring out what regressed it.

Comment 15

[Marco Bonardo [:mak]]

I made some Try builds here based on a recent Nightly, if you have a chance to test them with a new profile it may be useful to me, since I can't write automated tests for all the behaviors (native IME can't be emulated yet).
It should fix loss of the last word and Search Mode being lost when composition starts.
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/O0HzWxa3RsqN5bdwvkLgww/runs/0/artifacts/public/build/target.tar.bz2
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/YHGsd7AcQAavrRNt3pbCdQ/runs/0/artifacts/public/build/target.dmg
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/LF6a3iywTgCe81zj2xtGvw/runs/0/artifacts/public/build/target.zip

Comment 16

[Jaemin Noh]

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

I made some Try builds here based on a recent Nightly, if you have a chance to test them with a new profile it may be useful to me, since I can't write automated tests for all the behaviors (native IME can't be emulated yet).
It should fix loss of the last word and Search Mode being lost when composition starts.

Typing Korean (한글 시험) into address bar and pressing Enter works as expected for me (Windows 10).

However, combining with Search with feature is not working okay.
When I type go for Google, then press Tab, then type some Korean results in go한글.

Comment 17

[Marco Bonardo [:mak]]

Thank you, I can reproduce that bug, looking into it.

Comment 18

[Marco Bonardo [:mak]]

Attachment: Bug 1673669 - Fix Address Bar IME composition interaction with Search Mode and the Event Bufferer. r=adw

Fix a race condition with Korean IME, where it may submit delayed text after
Enter has been handled. The patch delays events if composition is still ongoing
and avoids using the selected element or the last resultForValue if it's not
yet complete by the time we submit the text.
Unfortunately this cannot be tested automatically in mochitests because it
depends on a native behavior of the IME that synthesize methods can't reproduce.

Additionally this fixes Bug 1679697 by ensuring Search Mode is not dismissed
by IME and the urlbar value is proper when confirming Tab-to-search.
This part comes with tests.

Comment 19

[Marco Bonardo [:mak]]

New builds, as usual please don't use your main profile or have a backup of it:
lin: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/X3U9pbp5TKaS1R_4wmzYYw/runs/0/artifacts/public/build/target.tar.bz2
mac: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/VBbwSsnzRuaLbsBt0GNq-g/runs/0/artifacts/public/build/target.dmg
win: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/YXHwtyMUQDie62kyBzbKBQ/runs/0/artifacts/public/build/target.zip

Comment 20

[Jun]

Tested Windows version. search by urlbar seems OK. Both reported error from me and Jaemin Noh haven't shown until now.

Comment 21

[Jaemin Noh]

I've tried the new build and the issue is gone.

I've also tried the Mac build with my Mac, which had not been updated and had Catalina installed. Everything is okay except the search suggestion window keeps flashing after each keystroke in Korean. It does not flash with the English input. FF84 also has no issue with flashing suggestion window.

Comment 22

[Marco Bonardo [:mak]]

Hm I don't see a difference on Windows related to the panel flashing, also compared to 83, unfortunately it opens and closes due to composition starting and ending. That may require a separate bug.
I'll do some testing on Mac and see what I can find.

Comment 23

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

The flashing is because the compositionstart listener closes the search popup (bug 1673971). I guess some race condition there causes immediate reopening.

Comment 24

[Marco Bonardo [:mak]]

yes, and afaict it is because on Mac each keypress sends compositionstart and compositionend, followed by an input event, thus compositionstart closes the panel and the input event after compositionend reopens it immediately.

I think we should work on that in a separate bug, either bug 1673971 or bug 1632597. A temporary solution for that, until we can easily distinguish IME opening a select from those not doing that, could be to add a, about:config pref that will keep the panel open and always search, so people interested can flip that pref, without us having to release an incomplete fix to everyone.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a0b52f4d44f2
Fix Address Bar IME composition interaction with Search Mode and the Event Bufferer. r=adw

Comment 26

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/a0b52f4d44f2

Comment 27

[Marco Bonardo [:mak]]

Comment on attachment 9191304 [details]
Bug 1673669 - Fix Address Bar IME composition interaction with Search Mode and the Event Bufferer. r=adw

Beta/Release Uplift Approval Request

• User impact if declined: IME for Korean and languages using similar IME behavior is broken, characters are lost, Search Mode is not correctly activated.
  We are aware it's late for Beta cycle, but this is badly affecting IME users and the urlbar is quite important in the users workflow.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce:

A. Lost chars
A.1. Type "foo 구문" (Korean IME, RNANS on QWERTY), or alternatively type "ㄴㅁㅇ" (ASD on QUERTY)
A.2. while the last char is still in composition mode (selected or underlined) press Enter
A.3. we should always search for the full string, intermittently this used to lost the last word

B. Search mode is broken
B.1. type @
B.2. Pick a search engine from the list
B.3. Type 구문
B.4. Search mode should be preserved and not disappear

C. Tab to search is broken
C.1. Ensure typing go provides a Tab-to-search entry for Google
C.2. Type go, press TAB to enter search mode, type 구문 (Korean IME, RNANS on QWERTY)
C.3. Search mode should be preserved, Enter should search 구문 on Google

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The changes pretty much affect composition, they have been tested by a few users though Try builds and have tests. The only one not having an automated test is losing chars, because unfortunately it cannot be tested through our automation.
• String changes made/needed:

Comment 28

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9191304 [details]
Bug 1673669 - Fix Address Bar IME composition interaction with Search Mode and the Event Bufferer. r=adw

Pretty bad regression for impacted users from the sounds of it. Approved for 84.0rc1, but agreed that we definitely want QA to poke at it as much as possible.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/e2751ede8639

Comment 31

[Adrian Florinescu [:aflorinescu]]

Reproduced the issues on 84.0b8, then followed through validating the fix on:
84.0 RC1 - 2020-12-07 on Windows 10 and Mac 10.14.6, starting with the uplift scenarios from comment 27, bug 1679697, bug 1632597, plus dupes and expanding from there, although the scenarios are quite on the basic side, since I'm just a beginner in writing in korean or chinise IME.

Other than the below points, currently the issue also seems fixed to me:

• mac flashing while composing the korean words, which my understanding is that will be handled probably in bug 1673971

• on windows, also noticing search suggest is not shown sometimes while the last word still in korean IME composing mode (:mak is bug 1673971 handling this? )

I will mark the 84 flag verified without the Ubuntu verification for the time being, since I have had some issues with setting up any IME on my distro, which it takes a bit to fix.

I am also consider adding basic manual tests for IME in the search suite - which lacked this kind of coverage and will end up being run as part of Nightly Search regression test run - due 12/11 - hence leaving the 85 flag for then.

Comment 32

[Marco Bonardo [:mak]]

(In reply to Adrian Florinescu [:aflorinescu] from comment #31)

• mac flashing while composing the korean words, which my understanding is that will be handled probably in bug 1673971
• on windows, also noticing search suggest is not shown sometimes while the last word still in korean IME composing mode (:mak is bug 1673971 handling this? )

bug 1673971 will be the "current" solution until we can detect ime better, it requires to user to flip a pref though.

Comment 34

[Petruta Horea [:phorea], Desktop Test Engineering]

Verified fixed using Firefox 85.0b3 and latest Nightly 86.0a1 2020-12-18 under Ubuntu 18.04 64-bit as well. Closing considering this and the above comments.