`Query.start` shouldn't `await provider.tryMethod("isActive")`. Instead it
should call all providers at once and then await all the promises. Also make
some other simplifications and changes to `Query.start` in preparation for later
patches.
Factor out `notifyResults` into `Query._notifyResultsFromProvider` because the
next patch will use it.
Differential Revision: https://phabricator.services.mozilla.com/D74191
As a quick fix to bug 1632918, don't check for app updates until the user
triggers the update intervention. There will still be some jank, but it'll be
postponed until the user types a phrase that triggers the intervention, which is
much better than at the first urlbar use. To avoid the problem where we wouldn't
show an intervention at all the first time the update intervention is triggered
since the updater status in that case will be CHECKING, add an updater listener
to wait for the check to finish and add our result then.
We should look into a better long-term fix, like making the updater's IO async
or not checking for updates at all inside urlbar.
Differential Revision: https://phabricator.services.mozilla.com/D73001
Ignore whitespaces when tokenizing strings looking like data: urls.
Improve the tokenizer to better distinguish possible origins from text, by
using the domains whitelist.
Fix a regexp mistake uncovered by the test.
Differential Revision: https://phabricator.services.mozilla.com/D71791
Use the PSL list to evaluate whether user typed strings in urlbar are valid URLs.
Cleanup the URIFixupInfo.fixupChangedProtocol property to be set appropriately.
Auto-correct the most common suffix typos for com, net, org.
Stop using URIFixup to trim urls when the urlbar value is set, instead always trim,
then untrim on focus if the trimmed string would cause, on navigation, a search
instead of a visit. This saves us from doing the URIfixup work on page load and
tab switch, running it only when strictly necessary.
Fix the "Did you mean to go to" prompt to show a protocol, avoiding the
confusing (but funny) "did you mean to go to 'space'" prompts.
Differential Revision: https://phabricator.services.mozilla.com/D68796
I didn't remove the `allowSearchSuggestions` assignment even though it's not necessary due to the `defaultValue` addition. And I already queued the main patch for landing.
Differential Revision: https://phabricator.services.mozilla.com/D71249
* Add a new `allowSearchSuggestions` property to the query context. It defaults to true.
* `UrlbarInput` sets this property when it starts a query. If the event that started the query is a paste event and the pasted string's length is larger than maxChars, then don't allow suggestions. Otherwise do.
* `UrlbarProviderSearchSuggestions.isActive` returns false when `!context.allowSearchSuggestions`.
* `UrlbarProviderSearchSuggestions` doesn't truncate the query anymore.
* Keep the `browser.urlbar.maxCharsForSearchSuggestions` pref but use it only for pastes, and increase it from 20 to 100. I considered making a new pref but this way if a user changed it, then it still applies to pastes at least. I'm not sure it's important though.
Differential Revision: https://phabricator.services.mozilla.com/D70956
Before 1496578, URIFixup::keywordToURI used to do a synchronous IPC call to be
able to access search engines from the content process. Consumers of URIFixup
didn't care. Bug 1496578 moved the IPC messaging to the callers, in particular
nsDocShell, but assumed nsDocShellLoadState wasn't loading from content.
It looks like in some cases it does, so this adds another sync IPC call for
GetFixupURIInfo.
The total numer of sync IPCs should not change from before Bug 1496578, URIFIxup
was just doing it internally, while now it happens at the call point.
Note the long term plan would be for these docshell objects callers to just
handle URIs, while the UI code should do fixup.
Bug 1375244 tracks the removal of these sync IPC messages.
Differential Revision: https://phabricator.services.mozilla.com/D70607
--HG--
extra : moz-landing-system : lando
This is so that we can avoid needing mozSystemGroup (to get keypress for
non-printable keys), which in turn prevents racing with the native key event
listeners, see the second patch in bug 1624657.
This turned out to be a bit tricky, because we need to guarantee the ordering of
the search one-offs handling in the searchbar with the usual autocomplete-input
handling. We could try to move this to the popup subclass but this is already a
bigger patch than what I'd like.
We can also revert the customElements.js change I did in bug 1624657, as the bug
is no longer relevant.
Differential Revision: https://phabricator.services.mozilla.com/D69743
--HG--
extra : moz-landing-system : lando
