1530706 - [Intermittent] Japanese word suggestions are wrongly displayed under the address bar's search suggestions when search handoff is enabled

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Ciprian Muresan [:cmuresan], Formerly of Ecosystem QA - please needinfo @mcoman for things regarding the team]

[Affected versions]:

• Firefox Nightly 67.0a1, Build ID 20190225102402
• Firefox Beta 66.0b10, Build ID 20190221160854

[Affected Platforms]:

• All Mac

[Prerequisites]:

• Have a Japanese keyboard enabled as default.

[Steps to reproduce]:

1. Start the browser and open a new tab.
2. Focus the in-content Search bar.
3. Type a few characters in quick succession.
4. Observe the Address bar.

[Expected results]:

• The keyboard's suggestions are displayed over the search suggestions.

[Actual results]:

• The keyboard's suggestions are displayed under the search suggestions.

[Notes]:

• Search handoff is not on by default on Beta so you need to set "browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar" to True.
• The issue is intermittent and you really need to type fast in order to reproduce.
• Attached a screen recording of the issue: Link

Comment 1

[Ricky Rosario [:rrosario, :r1cky]]

:cmuresan, does this also happen if you focus the awesome bar normally and type real fast? Or only when doing search hand-off?

Comment 2

[Ciprian Muresan [:cmuresan], Formerly of Ecosystem QA - please needinfo @mcoman for things regarding the team]

@r1cky, nope, if I focus the awesome bar normally and type slow or fast I get the word suggestion dropdown and no search suggestion. I get search suggestions only after I choose a word from the word selector.
It's only when I use search handoff. It looks like the awesome bar automatically assumes I wrote a valid word and tried to get me search suggestions.

Comment 3

[Ricky Rosario [:rrosario, :r1cky]]

This also happens in about:privatebrowsing with "browser.privatebrowsing.searchUI" enabled.

From what I can tell, it is a race condition between the search suggestions dropdown and the IME keyboard dropdown. The search suggestions dropdown is triggered by calling urlbar.search() on the first "compositionstart" event.

Comment 4

[Marco Bonardo [:mak]]

Likely we open the panel without first checking if composition is happening, when composition is happening we are supposed to only show the composition panel, but not the results popup. Though search() invokes startSearch regardless.
It is likely simpler to fix this in the quantum bar code.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Is this a regression in 66?

Comment 6

[Marco Bonardo [:mak]]

I think this is just something overlooked when aliases were added to the new tab page, I don't think it's a regression at all.

Comment 7

[Marco Bonardo [:mak]]

I can't reproduce the bug with the quantumbar enabled, so it looks like the method we use to handle composition events is more solid. It's matter of deciding whether it's worth trying to fix it in the old code, provided it may not be trivial because the legacy code is a lot more spreaded around and harder to follow.

Comment 8

[Marco Bonardo [:mak]]

Attachment: Bug 1530706 - IME may be displayed along with the urlbar results panel. r=Standard8!

Comment 9

[Marco Bonardo [:mak]]

The patch also fixes a bug in Quantum Bar found thanks to the new test.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b20f59942a1e
IME may be displayed along with the urlbar results panel. r=Standard8

Comment 11

[Razvan Maries]

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

Comment 12

[Marco Bonardo [:mak]]

Comment on attachment 9051645 [details]
Bug 1530706 - IME may be displayed along with the urlbar results panel. r=Standard8!

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: None
• User impact if declined: the IME editor may be presented below the urlbar panel, making impossible to use the urlbar properly in certain languages
• 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: comment 0 has all the information
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The urlbar change in nsAutocompleteController.cpp is simple, most of the code in the patch is about newly added tests and a fix in the Quantum Bar that is necessary to properly pass those tests (note: Quantum Bar is not enabled by default in 67 but we'll enable it in some experiments).
• String changes made/needed: none

Comment 13

[Pascal Chevrel:pascalc (PTO until Sept 2)]

Looks safe but I'd like to see this bug verified on nightly before uplifting it to beta, so adjusting the QE flag.

Comment 14

[Paul_B]

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

I managed to reproduce the issue on the Nightly build reported initially.

Verified as fixed after updating to the latest Nightly build (20190320112939). The issue does no longer reproduce, as the suggestions are now displayed in the bottom left corner of the window.

Comment 15

[Pascal Chevrel:pascalc (PTO until Sept 2)]

Comment on attachment 9051645 [details]
Bug 1530706 - IME may be displayed along with the urlbar results panel. r=Standard8!

Fix for a P1 bug in Quantum bar, verified on Nightly, uplift approved for the next beta, thanks!

Comment 16

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/5aa8eacca7b5

Comment 17

[Paul_B]

I managed to reproduce the issue on the 66.0b10 build reported initially.

Verified as fixed after updating to the latest Beta build. The issue does no longer reproduce, as the suggestions are now displayed in the bottom left corner of the window (like on Nightly).