* Rename the browser.urlbar.onQueryReady event onBehaviorRequested to make its purpose and return value clear.
* Add a browser.urlbar.onResultsRequested event that's fired when a query starts so that providers can add results. Listeners should return an array of Result objects. Add the Result type. It has a `payload` property that can be an arbitrary object depending on the result type.
* Add a browser.urlbar.onQueryCanceled event that's fired when a query is canceled.
* Rename the QueryContext type to just Query. From an extension's point of view, there's no difference between Query and QueryContext like there is for the internal implementation, so "Context" is unnecessary imo.
* Internally, remove the extension listeners map from UrlbarProvidersManager. Instead, extension listeners are added directly to UrlbarProviderExtension instances, and then UrlbarProvidersManager just loops through extension providers, not a separate map of listeners.
* Since UrlbarProviderExtension is getting a little bigger, move it to its own file.
* Fix a bug in UrlbarMuxerUnifiedComplete where the heuristic result sometimes does not come first in the sorted results, depending on the timing of when results from UrlbarProviderUnifiedComplete and other providers are added.
* Move SkippableTimer to UrlbarUtils.jsm, add a logger property, and add a name property so that it's easy to figure out which timers time out.
* Add lots of tests.
Differential Revision: https://phabricator.services.mozilla.com/D34809
--HG--
extra : moz-landing-system : lando
and migrate an existing test to use `TelemetryTestUtils.assertEvents`,
with a regular expression as filter.
Differential Revision: https://phabricator.services.mozilla.com/D35156
--HG--
extra : moz-landing-system : lando
The problem is that on switching back to the first tab (see the bug), userTypedValue is non-null when URLBarSetURI is called. Therefore the proxy state can't be valid. Something about bug 1529931 caused userTypedValue to go from null to non-null in this case. Details below, but the summary is that we shouldn't be calling UrlbarInput.setValueFromResult when opening the history popup, because setValueFromResult sets userTypedValue.
Before bug 1529931, result.autofill would always be undefined for the first result in the history popup, because we didn't allow UnifiedComplete to return an autofill result for the search triggered by the history popup. After that bug, UnifiedComplete could return an autofill result in that case -- and it likely would since the first result in the history popup has a very high frecency, which also makes it eligible for autofill.
The problem with having an autofill result in the history popup is that it triggers the input.setValueFromResult() call in UrlbarController.receiveResults [1], and setValueFromResult sets userTypedValue. So when the user opens the history popup, userTypedValue gets set to a non-null value (input._lastSearchString).
The fix is to not allow autofill for the history popup. After making that fix on revision https://hg.mozilla.org/mozilla-central/rev/5e2a3b886e64, the bug went away.
However, after I made that fix on a fresh tree, the bug still happened. It turns out that input.setValueFromResult still ends up getting called, by UrlbarView._selectItem [2], which is called when results are received [3]. The fix for this afaict is just to pass `updateInput: false` to _selectItem.
The autofill-related fix doesn't seem to be necessary at all anymore (likely due to the substantial changes to autofill since that bug landed), but I left it in anyway since it seems right to not allow autofill results for the history popup.
One other useful bit of info is that userTypedValue is set to null by tabbrowser on page load [4], so that's how userTypedValue has a null value when the bug manifests and it goes from null to non-null.
[1] https://hg.mozilla.org/mozilla-central/file/5e2a3b886e647af1968b9e52a6672bdeee2a0d6f/browser/components/urlbar/UrlbarController.jsm#l150
[2] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/components/urlbar/UrlbarView.jsm#685
[3] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/components/urlbar/UrlbarView.jsm#220
[4] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/base/content/tabbrowser.js#5118
Differential Revision: https://phabricator.services.mozilla.com/D35505
--HG--
extra : moz-landing-system : lando
Bug 1545766 (D28442) tweaked PanelMultiView keyboard navigation to behave as expected for embedded browser elements.
This patch extends this to handle iframe elements such as used in the builtin Profiler panel.
In addition, it avoids setting tabindex="-1" on iframe and browser elements, since this breaks tabbing behavior in iframe elements (and possibly causes issues in browser elements as well).
iframe and browser elements are already focusable, so this isn't needed anyway.
Differential Revision: https://phabricator.services.mozilla.com/D34984
--HG--
extra : moz-landing-system : lando
Attributes that are related to Fluent-based strings intentionally weren't moved to element.dataset.
Differential Revision: https://phabricator.services.mozilla.com/D35113
--HG--
extra : moz-landing-system : lando
Drew Willcoxon
Gabriele Svelto
YUKI "Piro" Hiroshi
rdalal
Michael Kaply
Ed Lee
Mihai Alexandru Michis
harry
prathiksha
Abdoulaye O. Ly
Erica Wright
Michael Krasnov
meandave
Tim Huang
Dão Gottwald
Rob Wu
Nihanth Subramanya
Dale Harvey
Csoregi Natalia
James Teh
Marco Bonardo ext:(%20%3Cmbonardo%40mozilla.com%3E)
Christoph Walcher
Gijs Kruitbosch
Jared Wein
Narcis Beleuzu
Alexander Surkov
Henri Sivonen