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
This updates the non-localized strings that appear in the Firefox Suggest
preferences UI with the final approved strings.
Differential Revision: https://phabricator.services.mozilla.com/D131031
This updates the Privacy pane for the new Firefox Suggest preferences spec.
Please see the spec here: https://mozilla-hub.atlassian.net/browse/SNT-37
The Jira description is a little out of date, and the wording of these new
strings (which are not exposed to localizers) isn't finalized, but I'm told the
structure of the UI is final more or less.
There is also a Figma here: https://www.figma.com/file/seJ2ZA4v3FgoV7jCxUR74B/Firefox-Suggest-exploration?node-id=3197%3A55695
We're replacing the current two Firefox Suggest checkboxes with three toggle
buttons. The first two toggle buttons correspond to the existing
`browser.urlbar.suggest.quicksuggest` and
`browser.urlbar.suggest.quicksuggest.sponsored` prefs. However, the second pref
is no longer dependent on the first, and it can be toggled regardless of whether
the first is enabled. The third toggle corresponds to a new pref,
`browser.urlbar.quicksuggest.dataCollection.enabled`. It can also be toggled
independently of the others.
In addition, we're adding an info bar/box below the toggles to explain to the
user the effect of their toggle selection. The text in the box depends on the
state of the toggles. The box itself is hidden when all three toggles are off.
Depends on D129224
Differential Revision: https://phabricator.services.mozilla.com/D128661
This does a couple of things:
* Instead of using the `not_now` telemetry event object for the cases where the
dialog is closed by the Escape key or some other atypical way, reserve
`not_now` -- renamed `not_now_link` -- specifically for clicks on the "Not
now" link and add two new objects: `dismissed_escape_key` and
`dismissed_other`. That should give us a little better understanding of how
the dialog is being dismissed. The new `not_now_link` name is to avoid
conflation with the previous meaning of `not_now`.
* Add a new `browser.urlbar.quicksuggest.onboardingDialogChoice` pref that
stores exactly the same values as the telemetry event. e.g., if the dialog is
accepted, then we'll record a telemetry event whose object is `accept` and
we'll also store `accept` in the pref.
I figure if we decide to show the onboarding again for people who have already
seen it, (1) we'll use this pref to decide the flow for any given user, and (2)
we'll need to add another pref for the user's response to the "v2" dialog, or
maybe we could morph this one into an array of responses or something more
complex like that.
Differential Revision: https://phabricator.services.mozilla.com/D127354
Give `tabindex` attributes to each focusable element and handle enter keypresses
(via the `dialogaccept` event) on them. The tab index ordering is:
1. Accept button (initial focus)
2. Settings button
3. Learn more
4. Not now
Also give `#infoBody` a tab index of -1 so it doesn't receive focus. It does
normally for some reason.
The accept button still does not have a focus ring initially. When you hit tab
the first time, the focus ring appear on the settings button. IMO it's better
not to show the ring initially since most people won't be interacting with the
dialog with the keyboard, and even those that do don't necessarily need to see
it initially. If we do want it initially, calling `focus` on the button in a
load event listener works.
On Windows (and maybe Linux?), the arrow keys still move around the elements
until the focus gets stuck on the Not now link. After that the arrow keys don't
work anymore but the tab key still does. Not sure how to fix that part.
Differential Revision: https://phabricator.services.mozilla.com/D125616
Per spec, the informational description about data collection under the main
Firefox Suggest checkbox should be hidden except for the "online" scenario,
since only the online scenario sends data to Mozilla.
We're also changing the two checkbox labels and adding another description under
the sponsored checkbox.
Depends on D125024
Differential Revision: https://phabricator.services.mozilla.com/D125031
Summary of changes:
* Remove the Sponsored action text for Firefox Suggest sponsored results
* Instead show Sponsored below their titles
* Remove the Firefox Suggest action text for non-sponsored results
This uses the action text for "Sponsored" as we do now, but it wraps it below
the title.
The Figma spec (link in Jira ticket) shows URLs in Firefox Suggest results, the
same as history results. I asked Natalie about it, and that's not correct, or at
least we shouldn't implement that now. If we do need to show URLs, then this
approach is probably worse than D124519 because wrapping the action would also
force the URL on a new line since the URL comes after it.
Differential Revision: https://phabricator.services.mozilla.com/D124563
This implements the spec in https://mozilla-hub.atlassian.net/browse/SNT-26, but
Natalie and I have made some tweaks over Slack that aren't reflected in that
ticket.
We want to move the Firefox Suggest preferences from the Search pane to the
Address Bar section of the Privacy pane. There are now two Firefox Suggest
checkboxes instead of one: a main one that enables Firefox Suggest suggestions
and another one that enables sponsored suggestions separately. If the main one
is checked but the sponsored one isn't, then the user will see only
non-sponsored suggestions.
I renamed and modified the browser_searchQuickSuggest.js test I added in
D105701, but a lot of the test changed and it's probably not helpful to look at
the diff against the old version.
Previously strings were hardcoded in search.js. I've added the new ones to the
new preview Fluent file for Firefox Suggest.
Depends on D124300
Differential Revision: https://phabricator.services.mozilla.com/D124431
This adds preview localizations for remaining Firefox Suggest strings.
I removed support for `payload.helpTitle` and `sponsoredText`. The `helpTitle`
code comment says it's useful for experiments with hardcoded strings, but we're
not shipping experiments as extensions anymore, and in-tree experimental/
in-development features should use preview localizations AFAICT.
Covered by existing tests:
* browser/components/urlbar/tests/browser/browser_helpUrl.js
* browser/components/urlbar/tests/browser/browser_quickSuggest*
* browser/components/preferences/tests/browser_searchQuickSuggest.js
Depends on D122550
Differential Revision: https://phabricator.services.mozilla.com/D123032
