This makes sure the row label transfers to the dismissal acknowledgment tip, if
the dismissed row has a label.
With that fixed, there's one other cosmetic problem where the tip's top border
is right up against the row label. It doesn't look good. I added some additional
space between the label and border.
Differential Revision: https://phabricator.services.mozilla.com/D203559
This adds a "Local recommendations" group label for Yelp suggestions.
It also caches all Suggest group labels to avoid pop-in in the urlbar view. The
MDN and Pocket labels weren't being cached.
Differential Revision: https://phabricator.services.mozilla.com/D201157
Fixes code to properly run tests with the feature enabled.
Fixes code not considering payload.userContextId is set to -1 for private
windows.
Fixes a bug in the _openTabs Map where multiple open tabs to the same url are
not properly counted.
Differential Revision: https://phabricator.services.mozilla.com/D200036
This fixes the two `#addExposure()` calls in `UrlbarView.#updateResults()` so
that hidden exposures are properly counted. Right now we overcount them because
we record them in cases where the result would not have been shown anyway.
The new test tries to cover all possible `UrlbarView.#updateResults()` paths:
* When the view is full and a new result can't replace any of the old rows, the
new result is appended and hidden. If the query is then canceled, the new row
will never be shown
* When the vew isn't full, a new row can be appended and visible immediately
* When a new row replaces an old row, it can be visible immediately
Differential Revision: https://phabricator.services.mozilla.com/D199176
#selectedElement may end up pointing to disconnected nodes. And so the public
.selectedElement getter.
This is how it was happening: a first call to onQueryResults adds and selects a
heuristic result. Then a second call to onQueryResults brings a new heuristic
result that requires new content (not compatible with the previous one), so the
old heuristic is emptied out, and new DOM is generated.
Because the code in onQueryResults relies on .selectedElement, at the second
invokation it thinks the selection is still valid, and doesn't select the new
heuristic. In reality .selectedElement at that time is pointing to a removed
DOM node.
The patch introduces a #rawSelectedElement and converts #selectedElement
into a getter.
Plus some minor logging improvements, and removing unused #mainContainer property.
Differential Revision: https://phabricator.services.mozilla.com/D195779
This is a hack for the experiment and likely not ideal for screen readers, but better than what we have. I'm reaching out to a11y folks to figure out the right long-term solution here. I'll make an effort to get that ready for the experiment too, but would like to get this landed as a backup.
Differential Revision: https://phabricator.services.mozilla.com/D194501
This removes "best match" as its own separate Firefox Suggest feature. In the
future, whether or not a suggestion is a best match (a.k.a. top pick) will be
determined by relevant product requirements. I've confirmed this with Nive.
Here's a summary of changes:
* Removes prefs and Nimbus variables related to best match
* Removes the "Top pick" checkbox in about:preferences
* Removes support for the `best_match` quick suggest config property. This
property was removed from the config in remote settings a while ago.
* Removes legacy telemetry scalars related to best match. These scalars were
added years ago for the original best match experiment and before we started
using Glean. In the case of non-sponsored suggestions, the scalars have not
been recorded at all for some time. In the case of sponsored suggestions, they
can now be recorded again due to the recent addition of sponsored priority
suggestions, but they are superseded by Glean.
Differential Revision: https://phabricator.services.mozilla.com/D190516
This expands D190144 so we check for actions as well as URLs. I also modified
tests for the affected row types so they test the visibility of the separator.
Differential Revision: https://phabricator.services.mozilla.com/D190494
This sets `has-url` on dynamic-result-type rows when their view template
contains a `.urlbarView-url` element. This fixes the missing separator in both
addon and weather rows.
This does not address one remaining problem: When `wrap` is set, the separator
is still missing in addon rows because they don't handle wrapping. Prior to
bug 1855639, they just always showed their title separator, and since they don't
wrap their URL, that was fine. I'd like to handle that separately by converting
addon rows from dynamic to standard. I filed bug 1857137 for that.
Differential Revision: https://phabricator.services.mozilla.com/D190144
The new Rust implementation of Suggest stores icons for some suggestion types in
its Sqlite database, and it returns these icons to consumers as byte arrays. To
show these icons in the view quickly and without any overhead, we can create
`Blob` URLs from the arrays. Blob URLs need to be revoked when we're done with
them to avoid leaking the backing data.
This patch implements some simple lifetime management of blob URLs in the view.
The first time the view shows a result, it creates a blob URL for the result's
icon. The view caches the URL while it remains open, so as the user continues to
type and possibly match the same result many times, the view will use the same
blob URL each time. When the view closes, it revokes the URL. This seems like a
reasonable, natural lifetime for these URLs, and the implementation is simple.
Depends on D189452
Differential Revision: https://phabricator.services.mozilla.com/D189615
The detail value for overflow events is:
0 - vertical
1 - horizontal
2 - both
This could cause the urlbar overflow state to be incorrect in some
cases.
Not sure how to test this, I found it via code inspection.
Differential Revision: https://phabricator.services.mozilla.com/D189547
The problem is that showing the dismissal acknowledgment tip does not remove the
result from the query context, so when the view later opens and reuses the
cached query context, it still has the dismissed result in it.
At first I thought I should modify `UrlbarView.acknowledgeDismissal()` so it
either invalidates the context cache or removes the result from the cached
context, but I saw that dismissals without the acknowledgment tip do not have
this problem. That's because they go through `UrlbarController.removeResult()`,
which removes the result from the context and then notifies the view.
The real problem is that I implemented dismissal acknowledgments wrong. They
should start by going through `UrlbarController.removeResult()` too.
This patch updates all callers of `acknowledgeDismissal()` so they call
`removeResult()` instead. To signal that an acknowledgment should be shown, they
first set a `result.acknowledgeDismissalL10n` property. When the view is
notified that a result was removed, it shows the tip if this property is
present.
Differential Revision: https://phabricator.services.mozilla.com/D187830
This enables addon suggestions by default (treatment B, no stars) for all
Suggest users. As discussed on Slack, I did not remove the related prefs and
Nimbus variables in case something goes wrong and we need to disable the feature
ASAP. In that case, we can ship a Nimbus rollout to re-disable it. After a
release cycle or two without any problems, we can do a follow-up that removes
them. I also left the treatment A implementation. We can remove that in a
follow-up too.
Since I did leave the prefs and variables, I only had to change their default
values to enable the feature with treatment B.
One problem is that addon suggestions should be best matches, but we don't want
to set `bestMatch.enabled` to true by default. To work around that, I set the
related best-match properties on the `UrlbarResult` inside `AddonSuggestions`
instead of delegating it to the quick suggest provider. Product has requested
that we remove the "Top pick" checkbox from about:preferences, and at that time
we should also remove the `bestMatch.enabled` pref. In the future, results
should be best matches on a case-by-case basis.
This makes a few UI changes that aren't strictly related but I wanted to fix
since more users will now see these suggestions:
* Cache the "Firefox extension" group label to prevent pop-in.
* Align the URL and row title by baseline. Right now the URL is too high above
the title.
* Set `inline-margin-end` of the icon so it's symmetrical with the starting
margin/padding. The current value of 8px is hardcoded and too small.
Differential Revision: https://phabricator.services.mozilla.com/D187640
Different providers have different time characteristics, reusing results across
providers may thus cause flicker of results coming from the fastest ones.
Differential Revision: https://phabricator.services.mozilla.com/D183507
