Closed Bug 1723158 Opened 3 years ago Closed 3 years ago

Allow heuristic result to be experimentally hidden or not present


(Firefox :: Address Bar, task, P2)




93 Branch
92.2 - Jul 26 - Aug 8
Tracking Status
firefox92 --- fixed
firefox93 --- fixed


(Reporter: adw, Assigned: adw)




(Keywords: perf-alert)


(2 files)

As part of an MVP prototype for the next phase of Firefox Suggest, we want to remove the heuristic result and instead show a top hit result(s). We'll need to implement this behind a pref so we don't affect the usual Firefox behavior and also so that product can experiment with having both a heuristic and top hits.

I'm not sure yet if it will be better to simply hide the heuristic or to not create it at all. Only hiding it seems like the less invasive approach for now.

This adds browser.urlbar.experimental.hideHeuristic. When true, the heuristic
is hidden in the view except for the search tip heuristic.

This is implemented as part of the larger prototype described in the JIRA ticket
(see the bug for a link) and some Slack conversation. There isn't much of a spec
in that ticket, and I think that's OK because we'd like to iterate on a
prototype and we're not sure yet how exactly the UX should work.

For example, should the heuristic always be hidden or only in certain cases?
This revision always hides it (except search tips), but it's easy to imagine
we'll want to introduce some more sophisticated logic. Or more simply we may
want to always show specific types of heuristics, like omnibox, as this revision
does for search tips.

The implementation works by excluding the heuristic in the view. Each heuristic
provider still creates their heuristics. When the view receives the heuristic,
instead of adding and selecting it, it calls input.setResultForCurrentValue()
so that the heuristic is set as the current result. When the user presses enter,
the input checks experimental.hideHeuristic and whether the current result is
a heuristic.

Pushed by
Allow heuristic result to be experimentally hidden or not present. r=mak
Regressions: 1724786
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch

== Change summary for alert #30909 (as of Thu, 12 Aug 2021 11:55:45 GMT) ==


Ratio Test Platform Options Absolute values (old vs new)
5% bing fnbpaint android-hw-g5-7-0-arm7-shippable-qr warm webrender 310.94 -> 294.58
5% bing FirstVisualChange android-hw-g5-7-0-arm7-shippable-qr warm webrender 359.79 -> 343.42
3% bing FirstVisualChange android-hw-g5-7-0-arm7-shippable-qr warm webrender 355.46 -> 346.25
2% bing ContentfulSpeedIndex android-hw-g5-7-0-arm7-shippable-qr warm webrender 620.38 -> 607.92

For up to date results, see:

Blocks: 1729195

Marking qe-verify- because some urgent Firefox Suggest patches we want to uplift depend on this bug, but this bug is not related to Firefox Suggest and does not need to be verified by QA for the Firefox Suggest rollouts.

This bug is a prerequisite of the larger experimental UX work in bug 1723160, and we can use that bug for QA verification of that work.

Flags: qe-verify-
Flags: in-testsuite+

[Tracking Requested - why for this release]: Some urgent Firefox Suggest patches we want to uplift to a 92 dot release depend on this bug.

We're tracking the metabug for this work.

Approval Request Comment
[Feature/Bug causing the regression]: Firefox Suggest offline/online rollouts (this bug is not directly related but code that is directly related depends on it)
[User impact if declined]: Needed for important rollouts on 93 and 92
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: No
[Needs manual test from QE? If yes, steps to reproduce]: No, low-level change with no visible changes
[List of other uplifts needed for the feature/fix]: See uplift coordination spreadsheet
[Is the change risky?]: Low risk relative to other uplifts needed in the patch stack
[Why is the change risky/not risky?]: This patch adds an experimental feature that is preffed off. It has no visible changes. Comes with a test and has baked on 93 and 94 for a while now.
[String changes made/needed]:

Attachment #9240780 - Flags: approval-mozilla-release?

Comment on attachment 9240780 [details] [diff] [review]
92/mozilla-release patch

Approved for 92.0.1.

Attachment #9240780 - Flags: approval-mozilla-release? → approval-mozilla-release+
Regressions: 1747575
You need to log in before you can comment on or make changes to this bug.