Closed Bug 1530706 Opened 7 months ago Closed 6 months ago

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

Categories

(Firefox :: Address Bar, defect, P1)

All
macOS
defect

Tracking

()

VERIFIED FIXED
Firefox 68
Tracking Status
firefox-esr60 --- unaffected
firefox65 --- unaffected
firefox66 --- wontfix
firefox67 --- verified
firefox68 --- verified

People

(Reporter: cmuresan, Assigned: mak)

References

Details

(Keywords: regression, Whiteboard: [fxsearch])

Attachments

(1 file)

[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

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

Flags: needinfo?(ciprian.muresan)

@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.

Flags: needinfo?(ciprian.muresan)

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.

Component: Activity Streams: Newtab → Address Bar

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.

Depends on: quantumbar
Priority: -- → P2
Whiteboard: [fxsearch]

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.

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.

Assignee: nobody → mak77
Status: NEW → ASSIGNED
Priority: P2 → P1

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

No longer depends on: quantumbar
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/b20f59942a1e
IME may be displayed along with the urlbar results panel. r=Standard8
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

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
Attachment #9051645 - Flags: approval-mozilla-beta?
Flags: qe-verify?

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

Flags: qe-verify? → qe-verify+

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.

Flags: qe-verify+
QA Whiteboard: [qa-triaged]
Flags: qe-verify+

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!

Attachment #9051645 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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).

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.