1687704 - Separate searchbar can lose focus after input with IME

Status: VERIFIED FIXED

(Firefox :: Search, defect)

Description

[Toshihiro Yamada]

After typing in search bar with IME, sometimes search bar lost its focus and focus moves somewhere (sometimes textbox in content, sometimes nowhere) instead of displaying suggestion popup.

I see it with both of nightly and 84.0.2, IMEs are MS IME and ATOK.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Harry Twyford]

A pref was introduced in bug 1673971 to keep the address bar panel open during IME composition. Setting browser.urlbar.imeCompositionClosesPanel to false should do it. Does that fix your issue?

Comment 3

[Toshihiro Yamada]

OK, try it. Take a few days to verify because I don't have reliable way to reproduce.

Comment 4

[Marco Bonardo [:mak]]

The urlbar should never lose focus anyway, with or without that option.

Comment 5

[Toshihiro Yamada]

I see the problem was reproduced when browser.urlbar.imeCompositionClosesPanel is false.
And it is my mistake not to report correctly, I see the problem with independent search bar not url bar.

Comment 6

[Harry Twyford]

Thank you for the clarification!

Comment 7

[Mark Banner (:standard8)]

Toshihiro, do you have specific steps to repeat with this? What platform are you on, how is it triggered?

Comment 8

[Toshihiro Yamada]

Currently, I don't have certain way to reproduce the problem.
Just after I determined the input with IME on separated searchbar, "sometimes" seachbar lost its focus instead it showed search suggestion popup.

I noticed this on 2 different version.

1. Win10 with ATOK and nightly.
2. Win10 with MS IME and release version(at least 84).

Noscript and ublock origin are installed both environments.

Comment 9

[Marco Bonardo [:mak]]

My suspect would be bug 1673299 here, it's the only thing I may think of that could shift focus

Comment 10

[Marco Bonardo [:mak]]

Daisuke-san, any idea if there may be a relation between bug 1673299 and events related to IME here?

Comment 11

[Daisuke Akatsuka (:daisuke)]

Attachment: search-suggestion.png

I am not sure yet that bug 1673299 causes this issue since this issue seems to happen before doing actual search.

I tried the following environments, but could not reproduce, unfortunately.

• Win10 with MS IME on Nightly 87.0a1 (2021-01-31), Release 85.0 and 84.02 with Noscript and ublock extensions.
• OSX 10.14.6 with ATOK for Mac Ver.31.2.0 on Nightly 87.0a1 (2021-01-31) .

What I did is:

1. Turn IME on.
2. Focus on the search bar.
3. Type "mojira".
4. Type enter key.
   Result: The search suggestion popup for "もじら" is shown.
   (See the attachment)
   Even I tried 3 and 4 many times, but could not reproduce.

Toshihiro-san, is the way I did to reproduce correct?

Comment 12

[Toshihiro Yamada]

Yes, but the problem is very very inconsistent. Sometimes it happened but in the other times it didn't happen even I did same thing. As far as I see, it doesn't happen continuously and occurs when I didn't care about it...

Comment 13

[Daisuke Akatsuka (:daisuke)]

Thank you very much.
Okay, as I will continue to use separated search bar, if I find something, will inform to here.

Comment 14

[Toshihiro Yamada]

I have tested for a while with simpler alert trapping and finally I succeeded to catch we could hit the change on bug 1673299 by only determined IME inputs.

this.textbox.onkeyup = event => {
if (
event.keyCode === KeyEvent.DOM_VK_RETURN &&
this._needBrowserFocusAtEnterKeyUp
) {
this._needBrowserFocusAtEnterKeyUp = false;
gBrowser.selectedBrowser.focus();
}
};

Next problem is why did this._needBrowserFocusAtEnterKeyUp become true.

Comment 15

[Toshihiro Yamada]

The problem is very wired. Normally, determine IME Input doesn't trigger handleEnter -> onTextEntered -> handleSearchCommand -> handleSearchCommandWhere function chain.
But when the problem happened, function chain was triggered and this._needBrowserFocusAtEnterKeyUp becomes true.

Comment 16

[Daisuke Akatsuka (:daisuke)]

Thank you very much, Toshihiro-san!
And I am sorry for my late replying.

As I can't reproduce it yet, prepared a patch that I added some logs to.
https://hg.mozilla.org/try/rev/051c320787dd94518af8ffbe82b4fb34814b77bf
This is the runnable image for Win10 including the logs.
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Qegymf9VSpqJ9cI0upwwlA/runs/0/artifacts/public/build/target.zip
If possible, could you try either?
When the problem happens again, as we can check the loga on Browser Console, could you send the logs here?

Comment 17

[Toshihiro Yamada]

Attachment: Bug 1687704_log.txt

Daisuke-san, Thank you for logging patch.
I tried my build with your patch and finally I got very interesting log.

The problem happens after onKeyup event of Return key didn't be called with some condition.

In bad log, former inputs in search bar ended with opening new tab by Alt+Ent.
Keydown event of both key are recorded but only Alt key's onKeyup event are recorded and that of Enter key didin't.
So needBrowserFocusAtEnterKeyUp keeps true after all process of searchbar ended.

Comment 18

[Toshihiro Yamada]

I'm not sure but I get a way to reproduce the problem constantly in my PC.

1. Input search word in searchbar
2. Alt+Enter to open new tab for search results and release Alt key first and after that release Enter key
3. Input search words with IME and determine.

Comment 19

[Alice0775 White]

I can reproduce this with STR of comment #18 in 84.0-87.0a1.
However, I need to repeat the STR twice.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4c449cde60a7ab3c7f305ffec29d56b04487bf43&tochange=5c2240a8de0beb7b1ea95921a8331bb256b7f59c

Comment 20

[Daisuke Akatsuka (:daisuke)]

Thank you very much, Toshihiro-san, Alice-775-san!
Yes, I also could reproduce the problem.
I will try to fix it.

Comment 21

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1687704: Reset needBrowserFocusAtEnterKeyUp when the searchbar lost the focus.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9816b307157e
Reset needBrowserFocusAtEnterKeyUp when the searchbar lost the focus. r=mak

Comment 23

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/9816b307157e

Comment 24

[Toshihiro Yamada]

Confirmed fixed.
Thank you very much!

Comment 25

[Daisuke Akatsuka (:daisuke)]

Thank you very much as well!

Comment 26

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I could not reproduce this issue, Daisuke can you still reproduce it?

Comment 27

[Daisuke Akatsuka (:daisuke)]

Hi Cristian,
I could confirm that this issue did not happen in the current nightly (88.0a1 (2021-02-23)).

Comment 28

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

Thank you!