Bug 1680022 - Add idMap property to getViewUpdate and prohibit dynamic results from setting their own IDs. r=adw, a=jcristau

Differential Revision: https://phabricator.services.mozilla.com/D100402

Differential Revision: https://phabricator.services.mozilla.com/D101412

Bug 1673669 - Fix Address Bar IME composition interaction with Search Mode and the Event Bufferer. r=adw, a=RyanVM

Fix a race condition with Korean IME, where it may submit delayed text after
Enter has been handled. The patch delays events if composition is still ongoing
and avoids using the selected element or the last resultForValue if it's not
yet complete by the time we submit the text.
Unfortunately this cannot be tested automatically in mochitests because it
depends on a native behavior of the IME that synthesize methods can't reproduce.

Additionally this fixes Bug 1679697 by ensuring Search Mode is not dismissed
by IME and the urlbar value is proper when confirming Tab-to-search.
This part comes with tests.

Differential Revision: https://phabricator.services.mozilla.com/D98768

Bug 1678765 - Fix broken "Search with" action text for heuristic results that are restyled to look like search results. r=harry

This was a little harder than it seemed like it should be because we show/hide
the title separator in two places, in `UrlbarView.updateRow` and in the CSS.
This patch gets rid of the show/hide in `updateRow`, so now we show/hide only in
the CSS. The decision to show/hide in `updateRow` was based on whether the
result has action text (`actionSetter`) or is a URL (`setURL`). We already had a
`has-url` attribute that corresponds directly to `setURL`, so adding a similar
`has-action` attribute that corresponds to `actionSetter` lets us show/hide only
in the CSS.

The second part of this patch is to actually fix the bug. For that, the existing
`show-action-text` attribute does part of what we want in the CSS: It forces the
action to be shown when a one-off is selected and there's no selected row. In
addition to that, we need to show the action when both a restyled search and a
one-off are selected, so this adds a new `restyled-search` attribute. We need
both attributes because we do not want to show the action for a restyled search
when some other row plus a one-off are selected (to match the current behavior).

Depends on D97843

Differential Revision: https://phabricator.services.mozilla.com/D98429

Differential Revision: https://phabricator.services.mozilla.com/D97023

Bug 1673669 - Fix Address Bar IME composition interaction with Search Mode and the Event Bufferer. r=adw

Fix a race condition with Korean IME, where it may submit delayed text after
Enter has been handled. The patch delays events if composition is still ongoing
and avoids using the selected element or the last resultForValue if it's not
yet complete by the time we submit the text.
Unfortunately this cannot be tested automatically in mochitests because it
depends on a native behavior of the IME that synthesize methods can't reproduce.

Additionally this fixes Bug 1679697 by ensuring Search Mode is not dismissed
by IME and the urlbar value is proper when confirming Tab-to-search.
This part comes with tests.

Differential Revision: https://phabricator.services.mozilla.com/D98768

Backed out changeset a507222dac63 (bug 1678765) for perma failures on browser_oneOffs_searchSuggestions.js. CLOSED TREE

Bug 1678765 - Fix broken "Search with" action text for heuristic results that are restyled to look like search results. r=harry

This was a little harder than it seemed like it should be because we show/hide
the title separator in two places, in `UrlbarView.updateRow` and in the CSS.
This patch gets rid of the show/hide in `updateRow`, so now we show/hide only in
the CSS. The decision to show/hide in `updateRow` was based on whether the
result has action text (`actionSetter`) or is a URL (`setURL`). We already had a
`has-url` attribute that corresponds directly to `setURL`, so adding a similar
`has-action` attribute that corresponds to `actionSetter` lets us show/hide only
in the CSS.

The second part of this patch is to actually fix the bug. For that, the existing
`show-action-text` attribute does what we want in the CSS; the only problem is
that we currently set it only when there's no selected row, but we need to also
set it when there's no selected row but a one-off is selected. We have a similar
block -- the one with a comment about restyling the heuristic to look like a
search result -- so I removed the block that currently sets/removes the
attribute and moved the set/removal there. I also renamed the attribute
`restyled-search` to better semantically describe what's happening, but if you
disagree I can restore the old name.

Depends on D97843

Differential Revision: https://phabricator.services.mozilla.com/D98429

Differential Revision: https://phabricator.services.mozilla.com/D95537

Bug 1670944 - Allow tabbing past tab-to-search results after focusing the Urlbar with the keyboard. r=mak

Differential Revision: https://phabricator.services.mozilla.com/D93601

Differential Revision: https://phabricator.services.mozilla.com/D92818

Bug 1665934 - Part 1.5 - Split _addDynamicStylesheet and _removeDynamicStylesheet out from UrlbarView into the file body. r=adw

Differential Revision: https://phabricator.services.mozilla.com/D93583

Bug 1671364 - Set "Sponsored" label for sponsored top sites in the address bar. r=mikedeboer,fluent-reviewers,flod

Differential Revision: https://phabricator.services.mozilla.com/D93637

Backed out changeset 342354dfd594 (bug 1665934)
Backed out changeset 56946d59bf0a (bug 1665934)
Backed out changeset 1b03418a14f6 (bug 1665934)
Backed out changeset 8c1edb639aa6 (bug 1665934)

Bug 1665934 - Part 1.5 - Split _addDynamicStylesheet and _removeDynamicStylesheet out from UrlbarView into the file body. r=adw

Differential Revision: https://phabricator.services.mozilla.com/D93583

This is a pretty simple implementation of the approach discussed in the bug. When a tab-to-search result is shown, we announce it to screen readers. We keep track of which engines are announced to be sure we don't keep announcing the same engine as the user types.

This approach is maybe slightly crude, but I didn't find a working elegant approach. One approach I considered is checking for tab-to-search results in the loop in UrlbarView._updateResults. After the loop is finished, if we found a tab-to-search result, we go back and change the aria-label on the action text of the prior result to something like "Visit, or press Tab to search with { $engine }. This didn't work because we don't read action text for the heuristic result as the user types. This is presumbably to avoid disrupting the user as they type. This is what my patch does regardless, however... Since Jamie was skeptical about whether we should announce this at all, I put this behaviour behind a default-true pref, browser.urlbar.tabToSearch.accessibility.announceResults.

Differential Revision: https://phabricator.services.mozilla.com/D93451

Differential Revision: https://phabricator.services.mozilla.com/D93411

This was more difficult to solve than I expected. The main issue is that the
`[open]` attribute on `#urlbar` wasn't accurate when the view was "open" but
there were no results or one-offs, so it was in fact closed. This broke a few
style rules.

This bug can also be reached when the user has no engines and clears the search
string while in search mode. This includes pressing Accel+K when typing a search
string while not in search mode.

The relationship between the UrlbarView and the one-offs is complex and depends
on a lot of listeners and async calls made in synchronous contexts. Furthermore,
most of the UrlbarView open/close code is synchronous, but checking the number
of engines (to determine if the one-offs will open) is an async operation. These
factors make it difficult for the view to discern any state about the one-offs
and plan accordingly.

First I tried adding a [oneoff] attribute to .urlbarView, set asynchronously when
the one-offs are built. Then I changed CSS rules to check
```
.urlbarView:not([noresults]),
.urlbarView[oneoffs]
```
instead of just `#urlbar[open]`. This approach would've required changing
a bunch of CSS from the simple `#urlbar[open]` to the more complicated CSS
above, which was not good for code readability. Also it would keep `[open]` in
a weird useless state where it couldn't really be trusted. This would've caused
other styling problems.

I settled on adding a `.then` call around the affected UrlbarView opening. The
view opens only if we are sure that we will have either results or one-offs,
so we can once again trust the `[open]` parameter. This approach has its
drawbacks. Mainly, it's a more JavaScript-heavy solution so it's possibly
slow. Thankfully, it's something that can be easily cached.

Differential Revision: https://phabricator.services.mozilla.com/D92526

Differential Revision: https://phabricator.services.mozilla.com/D92287

Bug 1668370 - Cycling through local one-offs changes the engine name in keywordoffer results. r=harry

Differential Revision: https://phabricator.services.mozilla.com/D92248

This patch adds tab-to-search results, partially reusing the existing code in `UrlbarProviderAutofill._matchSearchEngineDomain`. Tests are included. Telemetry is included in a child revision.

This patch doesn't add the "Search <engine name> directly from the address bar." action text. Our current action text code l10n is in a .properties file and I thought adding branching translation logic in UrlbarView would be a mess. I think Marco might be converting that .properties file to Fluent in bug 1658629. If he is, I'll rebase my patch on his and add the new action text it in this patch. If he isn't, I'll file a follow-up for converting that .properties file and adding the tab-to-search action text, which we can address before preffing `update2.tabToComplete` on. Either way, I think this is ready for a first-round review.

This patch is based on D91076 and D91077. It doesn't have any functional dependency, but there are some conflicts, especially in the added telemetry.

Differential Revision: https://phabricator.services.mozilla.com/D91468

Bug 1658629 - Update heuristic action when cycling through local one-offs with a search string. r=adw,fluent-reviewers,flod

Differential Revision: https://phabricator.services.mozilla.com/D91574

Bug 1678155 - Restyle all heuristic result types when a one-off is selected/search mode is previewed. r=harry

We currently restyle URL heuristic results when a one-off is selected/search
mode is previewed, but afaict we should restyle all types. In the case of this
bug, the heuristic is a search result. I ended up rewriting most of
browser_oneOffs_heuristicRestyle.js to check various result types (URL, search,
and keyword) and both Alt-arrowing and non-Alt-arrowing down to the one-offs in
case that makes a difference.

This fixes part of bug 1678765, the part where we do the wrong thing when a
restyled keyword result is picked. It doesn't fix the visual part where the
action text is flush against the title text.

This also fixes a small error in `UrlbarView._on_SelectedOneOffButtonChanged`
where we were using `result.payload.title` when restyling heuristics, but
`result.title` is the correct property.

Depends on D97376

Differential Revision: https://phabricator.services.mozilla.com/D97843

* Add prefs for each local search shortcut
* Remove the `update2.localOneOffs` pref since it's not necessary with the three
  new prefs
* Modify preferences UI by adding a new row in the engines tree for each local
  shortcut
* Add `UrlbarUtils.LOCAL_SEARCH_MODES` so we have a single place where local
  search modes and their properties are defined
* Add a new test file for the preferences UI
* Modify browser_oneOffs.js to test the three new preferences

Differential Revision: https://phabricator.services.mozilla.com/D97376

Backed out changeset 680264f74a86 (bug 1674485) for bc failures on browser_oneOffs_heuristicRestyle.js.

Differential Revision: https://phabricator.services.mozilla.com/D95537

Bug 1671241 - Set aria-activedescendant upon selecting a tab-to-search result if the user previously selected the tab-to-search result. r=mak

Differential Revision: https://phabricator.services.mozilla.com/D95214

Bug 1669526 - Don't show the heuristic result for partially typed token aliases and show all the matching token aliases. r=adw

The heavily nested structure of UrlbarInput.setValueFromResult made it difficult to handle a result that was both a keywordoffer and autofilled. I took this opportunity to refactor setValueFromResult to be flatter. I think it's a bit easier to read now.

Differential Revision: https://phabricator.services.mozilla.com/D94903

Differential Revision: https://phabricator.services.mozilla.com/D91123

Bug 1665292 - Clear the view's selected result and UrlbarInput._resultForCurrentValue when the view is cleared. r=harry

First, `UrlbarView.clear` needs to null the selected element. Second, setting
the selected element to null needs to also null
`UrlbarInput._resultForCurrentValue`. `UrlbarView._selectElement` does call
`input.setValueFromResult`, which sets `_resultForCurrentValue` -- but not if
the `updateInput` arg is false. So I added a new
`UrlbarInput.setResultForCurrentValue` method so `_selectElement` can set it. At
first I tried unconditionally calling `input.setValueFromResult`, but a bunch of
tests failed. I looked into it, but it's complicated, so I gave up and added
this new method.

This also makes some other changes that I'll comment on inline.

Differential Revision: https://phabricator.services.mozilla.com/D90360

Bug 1657918 - Don't add a heuristic result for empty searches in local search modes, and modify the view to allow it to stay open when empty. r=harry

This excludes the heuristic for empty searches when in search mode. I haven't
heard back from Verdi yet about excluding it for all searches in search mode. We
can add that in a follow-up if necessary.

Since we're now excluding the heuristic but we want the view to remain open,
it's possible for the view to be empty while it's open. I had to make some
changes to allow that to happen. There are three cases I want to call out:

1. When the search string is empty, the view shows top sites. If you then enter
   search mode and the resulting search doesn't return any results, we
   previously closed the view. This patch keeps it open. An example of this
   scenario is when you don't have any bookmarks and you click the bookmarks
   one-off.
2. When the urlbar isn't focused, it's in search mode, the input is empty, and
   the search didn't return any results, then focusing the urlbar didn't do
   anything previously. This patch auto-opens the view.
3. When the input contains a single char and it's in search mode, deleting the
   char previously closed the view if the empty search didn't return any
   results. This patch keeps the view open.

When the view is empty, we also need to hide the one-offs' top border that
usually separates them from the results. Otherwise there are two separator lines
right next to each other, the one above the one-offs and the one at the bottom
edge of the input. I don't think there's any CSS selector that will let us
easily do this due to the DOM structure, so I added a new `noresults` attribute
on the view for this.

I had to call `context.searchString.trim()` to tell whether the search string is
empty. Since we do that in a bunch of places, I added
`context.trimmedSearchString`, and a lot of this patch is replacing those `trim`
calls.

Differential Revision: https://phabricator.services.mozilla.com/D86908

I noticed when when working on browser_oneOffs_searchSuggestions > test_selectOneOffThenSuggestion.

Differential Revision: https://phabricator.services.mozilla.com/D86766

Bug 1667766 - Part 2 - Restyle URL heuristic results as search results when cycling through one-offs. r=adw

This patch replaces the heuristic's icon, title, and action text when cycling through the one-offs. One problem is that the underlying result is still of RESULT_TYPE.URL, so picking it would visit its underlying URL. One way to get around this would be to create a new search UrlbarResult and swap it with the heuristic result, or change all the properties of the UrlbarResult so it becomes a search result. These approaches were discussed in review and rejected because they break the design of the QuantumBar. Having the URL result navigate to a SERP when picked would also require a lot of flags and conditionals throughout our navigation logic, which isn't ideal. I settled on promoting search mode when one of these restyled results is picked. I admit that this is a bit of a strange interaction, given that something that looks like a search heuristic result behaves like a keywordoffer, but I think its preferable to us navigating to a URL the user cannot see in the UI. As discussed in review, this result can only be picked by clicking on it. The chance of a user clicking the heuristic result while arrowing through the one-offs is exceedingly slim, so it seems like a decent compromise between UX and engineering effort. It also means selecting the restyled result with click and Enter does the same thing, so it's not completely out of nowhere.

I checked a11y with this patch applied and things are mostly unchanged from a screen reader perspective. Currently, typing the string "moz", alt+arrowing to the first one-off, then selecting it will create announcements like: "m", "o", "z", "Selection replaced. Google (@google), button", "Selection replaced. moz, Search with Google, edit text". The same annoucements are made with this patch applied. Pressing down arrow (not alt) will announce the second result. Arrowing back up to the heuristic will announce the original autofill result, because the original autofill result has been swapped back in. I'll ping Jamie in the bug once this patch is mature.

Differential Revision: https://phabricator.services.mozilla.com/D94338

Bug 1667766 - Part 1 - Refactor UrlbarView._on_SelectedOneOffButtonChange and fix one-off selection papercuts. r=adw

This patch fixes two issues:

1. When a history result was autofilled, cycling through the engine one-offs would not change its icon (as expected) and cycling through the local one-offs would change its icon, but only to the history icon. This was because UrlbarView._iconForSearchResult was only checking for the result source and wasn't checking that the result was of search type as well. For consistency, we no longer change the icon when local one-offs are selected (we will change it once we figure out a way to change it for engine one-offs as well). I also renamed this method to _iconForResult to prep for Part 2 of this patch.

2. Typing a string, alt+arrowing through the one-offs, then pressing Enter flickers the heuristic result. This is because the one-off button is deselected, so we restore the original heuristic result. However, the search mode query also fires at the same time and quickly replaces the heuristic result. I added a check to not restore the original heuristic result in this case, eliminating the flicker.

This patch also refactors UrlbarView._on_SelectedOneOffButtonChanged. Previously, the main loop bailed early if a local one-off was selected, thus treating local one-offs as if they were very different from engine one-offs. This new flow handles both local and engine one-offs over the course of the same loop. I think it's a bit easier to read and understand.

Differential Revision: https://phabricator.services.mozilla.com/D94637

Differential Revision: https://phabricator.services.mozilla.com/D83854

Differential Revision: https://phabricator.services.mozilla.com/D85942

Bug 1654439 - Part 2: Factor out some urlbar-specific things from SearchOneOffs into UrlbarSearchOneOffs. r=harry

The base class retains the `popup` property, and now the `view` property is
entirely in the subclass. I defined some new methods so that the subclass can
easily customize behavior for a view that's not a popup. I used the name "view"
in these method names to refer to a generic view/panel. I didn't rename `popup`
`view` because the base class still assumes that `popup` is a `menupopup`.

We could/should probably get rid of the "compact" concept and instead specialize
the behavior even further in the subclass, but for simplicity's sake I left that
for now.

Depends on D84784

Differential Revision: https://phabricator.services.mozilla.com/D84785

This moves search-one-offs.js into a jsm without making any substantive changes,
adds a new subclass in UrlbarSearchOneOffs.jsm, and uses `UrlbarSearchOneOffs`
in `UrlbarView` instead of the base `SearchOneOffs` class. `UrlbarSearchOneOffs`
will be fleshed out in part 2.

Differential Revision: https://phabricator.services.mozilla.com/D84784

Backed out changeset c03e14b7c430 (bug 1654439)
Backed out changeset 51b575b0d605 (bug 1654439)

Bug 1654439 - Part 2: Factor out some urlbar-specific things from SearchOneOffs into UrlbarSearchOneOffs. r=harry

The base class retains the `popup` property, and now the `view` property is
entirely in the subclass. I defined some new methods so that the subclass can
easily customize behavior for a view that's not a popup. I used the name "view"
in these method names to refer to a generic view/panel. I didn't rename `popup`
`view` because the base class still assumes that `popup` is a `menupopup`.

We could/should probably get rid of the "compact" concept and instead specialize
the behavior even further in the subclass, but for simplicity's sake I left that
for now.

Depends on D84784

Differential Revision: https://phabricator.services.mozilla.com/D84785