This uses the new label but only when the addon suggestion is shown as a best
match. Otherwise the suggestion will be shown in the usual Firefox Suggest group
so it should use that label.
I chose `-brand-product-name`, which is always "Firefox" even on Nightly. I
don't think it makes sense to talk about "Nightly extensions".
Differential Revision: https://phabricator.services.mozilla.com/D179868
This implements the weather suggestion result menu UI and builds on D174941.
References:
* [Spec]( https://www.figma.com/file/Hdi0oHB7trRcncyVAKZypO/accuweather-explorations?node-id=2421%3A62540&t=29w6wH3UYchqBxqX-1) (See "A11y review" in the sidebar)
* [Clickable prototype](https://www.figma.com/proto/Hdi0oHB7trRcncyVAKZypO/accuweather-explorations?page-id=2192%3A42825&node-id=2394-52468&viewport=246%2C526%2C0.12&scaling=min-zoom&starting-point-node-id=2394%3A52468&show-proto-sidebar=1) (See "Revised 4/3" in the sidebar)
There are a couple important points about the menu. First, one of the commands,
"Report inaccurate location", is specific to weather suggestions, or at least
location-based suggestions. I don't think it's a good idea to centralize all
commands in UrlbarView, and in general I'd like to stop centralizing handling of
different result types in the view and input, so I added a new provider method
called `getResultCommands()`.
Second, the spec calls for a menu separator and a submenu so the user can select
a reason they don't want to see the result, so the return value of
`getResultCommands()` is flexible enough to support those two things, and I
modified `#populateResultMenu()` too.
These new commands will be recorded in Glean engagement telemetry as new
`engagement_type` values, same as "dismiss" and "help" currently are.
This patch doesn't implement handling of two of the commands, "Report inaccurate
location" and "Show less frequently", because I wanted to keep it focused on the
fundamentals described above.
Depends on D174941
Differential Revision: https://phabricator.services.mozilla.com/D174994
This patch changes the Firefox Suggest preference toggles to use the new `moz-toggle` element.
For testing purposes, set `browser.urlbar.quicksuggest.enabled` to `true` to make the toggles visible in `about:preferences#privacy`.
Differential Revision: https://phabricator.services.mozilla.com/D167881
This patch implements the following:
It gets a weather result by calling `_makeWeatherResult` which calls our backend
Merino server. Based on the data returned by Merino, it parses through the
results to display the city, url, provider, weather summary, current, high, and
low temperatues to the user. It checks for a 0-prefix result to display the
weather. Lastly, it includes a top pick label for weather.
Differential Revision: https://phabricator.services.mozilla.com/D166216
This does the following:
* Get rid of `QUICK_SUGGEST_SOURCE` since it's only used in a couple of
places. Its simpler to use the string literals directly.
* Set `source: "merino"` on Merino suggesions in the Merino client instead of
doing it in UrlbarProviderQuickSuggest, similar to how the remote settings
client sets `source: "remote-settings"`
* Export `ONBOARDING_CHOICE` and `ONBOARDING_URI` on the QuickSuggest object for
consistency with other consts
* Remove unnecessary consts from QuickSuggestTestUtils that are already defined
on QuickSuggest
Please see bug 1798595 for details.
Depends on D160986
Differential Revision: https://phabricator.services.mozilla.com/D160987
This moves code related to the onboarding dialog out of UrlbarQuickSuggest in
preparation for making UrlbarQuickSuggest strictly related to remote settings.
Please see bug 1798595 for details.
Depends on D160983
Differential Revision: https://phabricator.services.mozilla.com/D160984
This adds a block button to best match rows. The button looks similar to the `?`
help button. For best match rows, both the block and help buttons appear, with
the block button first.
Figma spec, see "Top pick proposal
for Firefox 99 - awesomebar":
https://www.figma.com/file/seJ2ZA4v3FgoV7jCxUR74B/Firefox-Suggest?node-id=4937%3A67136
This does not handle clicks on the button because that will be covered by bug
1754591 and bug 1754594.
To test this, the easiest way is still probably to pause browser_bestMatch.js.
You can use the `nonsponsored()` task to test the block button by itself and
`nonsponsoredHelpButton()` to test with a help button; pause before the
`promisePopupClose()` at the end. If that's not practical I can post my WIP for
triggering best matches and you'll need to enable Firefox Suggest too.
To implement this I generalized the existing help button code into a way to add
arbitrary buttons. Instead I could have duplicated it, but that's not as nice
and it makes the CSS a little uglier because we'd need rules for handling the
help button alone, the block button alone, and both (although there are no plans
to show the block button alone). In addition, eventually we want a way to report
inappropriate suggestions so there's been discussion about having a report
button too. It may turn out that we add a single `...` button for everything,
but it's not clear yet.
I tweaked the button style a little to match the new spec. Help buttons in the
usual Firefox Suggest rows will get these tweaks too of course. The help button
(and block button) are now smaller, have smaller margins, and their hover
background color is the same as the color for rows.
Finally, I noticed we're not correctly updating `item[role]` when reusing a row
and going from without a help button to with a help button, or vice versa, so
this fixes that too.
Differential Revision: https://phabricator.services.mozilla.com/D138508
This creates a new type of `bestmatch` row in the view. The UX spec is here:
https://www.figma.com/file/seJ2ZA4v3FgoV7jCxUR74B/Firefox-Suggest?node-id=5235%3A1284
(See: “Best match” proposal
for Firefox 99)
Best match rows look similar to standard rows except they have a large 52x52
icon with the title and URL vertically centered next to it. Best match rows that
are sponsored also have the usual "Sponsored" label.
We're targeting 99 for the initial MVP version of this feature. For the MVP,
best matches will always be quick suggest results. Long term, there's been
discussion about incorporating history and bookmarks too.
Since 99 is coming up soon and we don't have much time, I did what I think is
the most straightforward thing and added another new row type, `bestmatch`. I
considered using the usual row DOM, but it's tricky because for best match we
need to show both the URL and sponsored label, and the sponsored label needs to
be shown below the title. The way we show the sponsored label for typical quick
suggest rows is by putting it in the action text and wrapping it below the
title, but that doesn't work for best match since it must show the URL.
However, best match rows do look similar enough to the usual rows that I think
it would be worth modifying the usual row DOM so that it uses this new best
match DOM. That would simplify the JS and CSS. It's also a much larger, riskier
change and there might be disagreement about it, and I don't want to block this
feature on that, so I'd like to come back to it. I have a WIP in D137095 that
also includes some general refactoring and simplification.
I could have implemented this as a dynamic result type like the onboarding
tab-to-search, but that would couple best match to a particular provider --
quick suggest -- and as I mentioned we may end up expanding best match to all
types of results. I don't want to add a new type and all of that code if we know
we may remove it later.
This revision relies on a new `result.isBestMatch` property that will be set for
quick suggest best matches in D137250.
The best match DOM looks like this:
```lang=html
<span class="urlbarView-row">
<span class="urlbarView-row-inner">
<img class="urlbarView-favicon">
<span class="urlbarView-row-body">
<div class="urlbarView-row-body-top">
<div class="urlbarView-row-body-top-no-wrap">
<span class="urlbarView-title"></span>
<span class="urlbarView-title-separator"></span>
</div>
<span class="urlbarView-url"></span>
</div>
<div class="urlbarView-row-body-bottom">Sponsored</div>
</span>
</span>
</span>
```
Finally, this also adds a "Best Match" group label in the view. A few notes on
this:
* The string isn't finalized yet but we can easily update it once it is.
* Since right now best match will be en-US only and is related to Firefox
Suggest, I added the string to firefoxSuggest.ftl, which is not localized.
* In D137250 I'm adding a `browser.urlbar.bestMatch.enabled` pref and moving the
caching of this string behind that pref.
Differential Revision: https://phabricator.services.mozilla.com/D137097
Updating `aria-labelledby` and `aria-describedby` seems to work. We aren't using
`aria-live` correctly I think, which is my fault since I suggested it. AFAICT
that should be used on an element whose subtree changes. That's not the case for
these `h1` elements. It is the case for the `body` element, and I tried setting
`aria-live=polite` on it, but it ended up causing everything in the main section
to be read multiple times.
Differential Revision: https://phabricator.services.mozilla.com/D136055
There are a couple of problems:
(1) When a radio button has the keyboard focus, the corresponding title and
description are not read. This seems to be because the `<label>` doesn't have
any content to read. The actual content is in a different div.
I fixed this by moving the title and description inside the `<label>`.
(2) The options' titles and descriptions are not read on hover/mouseover. This
seems to be related to how the `<label>` has an absolute position and is layed
out on top of or underneath the titles and descriptions. It interferes with the
screenreader.
I fixed that by removing the absolute position. With that change combined with
the fix mentioned above, you can still click the title and description text to
select the radio button, but it breaks the ability to click outside the text to
select the button, for example clicking directly underneath the radio button. To
fix that, I gave the `<label>` a positive padding and negative margin so that
its padding extends to the border of the option.
* * *
I tested this on all three platforms and with the NVDA screenreader on Windows.
This revision makes one other change that isn't strictly necessary: Instead of
setting the width of the options to 100% - some margin, we can set
`align-items: stretch` on the section, which I think is a little nicer. We also
don't have to specify the widths of the images that way, only the heights.
However, it also makes the the buttons and not-now link take up the entire width
of the section, but we can fix that by putting them inside a div, which I called
`.buttonBox`.
Differential Revision: https://phabricator.services.mozilla.com/D135753
