This patch also addresses bug 1645293. It essentially reverts parts 1 and 3 of bug 1616700 for users with searching disabled. Since we had to introduce branching behaviour, there are some new constructs like a shouldHandOffToSearchMode multi-pref in UrlbarPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D118606
This patch also addresses bug 1645293. It essentially reverts parts 1 and 3 of bug 1616700 for users with searching disabled. Since we had to introduce branching behaviour, there are some new constructs like a shouldHandOffToSearchMode multi-pref in UrlbarPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D118606
There's more I'd like to do here. Namely, I want to eliminate the Search class in favour of everything being part of ProviderPlaces, and I'd like to get rid of "match" objects/nsIAutoCompleteResult in favour of always dealing with UrlbarResults. I think major changes like those are best left to bug 1717511. The latter change would require moving the muxer-lite deduping code from ProviderPlaces to the muxer. That way, ProviderPlaces can just send results to the muxer as soon as they're ready rather than needing to first order them inside an nsIAutoCompleteResult.
Differential Revision: https://phabricator.services.mozilla.com/D119308
UnifiedComplete must stick around to serve as an mozIPlacesAutoComplete implementation for XUL consumers like search.js and privacy.js.
Differential Revision: https://phabricator.services.mozilla.com/D119306
Apologies in advance for this review. It's the test I've had to rewrite the most. This is because the unifiedcomplete tests did not care about sorting, and urlbar tests do. Since this test does some complicated stuff with frecency, many of the expected matches had to be reordered in the test. The old test just listed all the uris in descending order in `matches`, paying no mind to frecency. As I've been doing with other tests, I reversed the order which with they are added to history/bookmarks, to reduce the number of changes required in the sets of expected matches.
That yielded this order, in descending order of frecency:
uri11
uri1
uri4
uri6
uri5
uri7
uri8
uri9
uri10
uri12
uri2
uri3
Differential Revision: https://phabricator.services.mozilla.com/D119113
This bug was introduced because UnifiedComplete was only filtering tokens when the queryContext contained a restrictToken. UrlbarProvidersManager was only setting queryContext.restrictToken when a source restriction token was typed (i.e. not including $ and #). This meant that # and $ were never filtered from the search string. This patch now sets restrictToken to whatever the first token is, including # and $. This ensures UnifiedComplete will always filter tokens when a restriction token is typed.
Differential Revision: https://phabricator.services.mozilla.com/D119197
When we duplicate a tab, we don't need to have about:blank load in it, because
we are going to use restore mechanism to copy data into the new tab. If we
don't skip the superfluous load, the restoring process might race with the
loading of about:blank, and sometimes we might try to destroy the
WindowGlobalChild actor just as SessionStore is trying to restore docshell
capabilities for that tab resulting in a rejected promise in _restoreHistory
and `_restoreHistoryComplete` not getting called.
Differential Revision: https://phabricator.services.mozilla.com/D119313
There are two substantive changes to test_protocol_swap worth pointing out:
1. Some subtests now search for <protocol>://sit instead of <protocol>://site. This is because the latter would make the heuristic result the same as the relevant history result and the history result would be deduped. We would thus lose test coverage for that history result.
2. Tests that expected allMatches no longer expect uri5. The muxer dedupes https://www. URLs in favour of https:// URLs.
Depends on D118636
Differential Revision: https://phabricator.services.mozilla.com/D118637
The last few subtests in test_tags_returnedInSearches.js got substantive changes. This is because urlbar tests reflect the results actually shown in the Urlbar and unifiedcomplete tests just tested what came out of UnifiedComplete. Those last few subtests tested that we show non-matching tags. While UnifiedComplete returns those non-matching tags, UrlbarProviderUnifiedComplete has filtered them out since bug 1522226.
Differential Revision: https://phabricator.services.mozilla.com/D118635
This patch will reduce the number of TTS results we show, because we will no longer allow some partially matched hosts. Previously, we let some TTS results through the muxer even when a domain was not autofilled because we thought the user might be typing a subdomain of the TTS domain. However, this created false positives, as demonstrated in the bug. This patch strikes a compromise by retaining the satisfiesAutofillThreshold property, but requires the heuristic result to be a URL result. That way, we can ensure the TTS engine domain has the same hostname as the heuristic URL. This patch still handles the Wikipedia and eBay cases that satisfiesAutofillThreshold was designed to address.
Differential Revision: https://phabricator.services.mozilla.com/D116644
This patch will reduce the number of TTS results we show. Previously, we let some TTS results through the muxer even when the heuristic URL was not similar to the tab-to-search engine. We did this because ProviderTabToSearch thought the user might be typing part of a TTS domain, but we didn't check that the actual heuristic result was for that domain. This patch allows tab-to-search results only when (1) the heuristic result is not a URL result or (2) the heuristic URL resembles the tab-to-search engine domain. This patch still handles the Wikipedia and eBay cases that satisfiesAutofillThreshold was designed to address.
Differential Revision: https://phabricator.services.mozilla.com/D116644
This patch creates a blocklist of sites that should not be saved as keyframes. The blocklist maps hostnames to regular expressions. While the map is a bit of an awkward structure, it lets us avoid checking every URL against a list of regular expressions. This performance gain will be more apparent as the list expands.
Differential Revision: https://phabricator.services.mozilla.com/D117543
The problem in this bug is that the sum of the available spans of child buckets
is not necessarily equal to the available span of the parent bucket. That's
because each child span must be an integer, but a child's ideal span may not be
an integer, so we have to round and an error can accumulate.
This fixes it by detecting that case and then tweaking child spans until their
sum is equal to the parent's available span. If the sum is smaller than the
parent span, then we increment child spans until it's equal; if the sum is
larger than the parent span, then we decrement instead. (The case where the sum
is larger isn't as much of a problem as when it's smaller. We still correctly
limit the total result span due to logic elsewhere, but the bucket's final
result composition may not reflect flex ratios as accurately as it could.)
I added some logic so that the child spans we choose to tweak are the ones that
minimize the mathematical error between the final integer spans and the ideal
unrounded spans. In other words, we pick the best spans possible given that they
must be integers.
We need to do this tweaking when we try to overfill buckets too, not only on the
first pass for a bucket. Currently the second pass is hardcoded in
`_fillBuckets`. Rather than hardcoding the tweaking in both places, I added an
`_updateFlexData` helper method. While I was doing that, I realized we may need
more than two passes per parent bucket in order to optimally fill the children.
So I modified `_fillBuckets` so it recurses with the parent bucket itself when
we need to overfill any of its children.
I also added support for both `availableSpan` and `maxResultCount`. That lets us
get rid of the ugly heuristic special case in `_addResults`. A bucket will be
filled while both its used span and result count are under both these limits.
This also removes support for zero flex. I got really annoyed with it while I
was working on earlier versions of this. It made the code unnecessarily complex.
I added zero flex kind of as a hack to support tail suggestions, but we don't
actually need it at all. We can just move the tail suggestions bucket out of the
main suggestions bucket with form history and remote suggestions.
Finally while I was here I switched from "bucket" to "group" in light of the
renaming in bug 1715484 and bug 1715822.
Differential Revision: https://phabricator.services.mozilla.com/D117582
I removed the part of the test that checks for a history result. That was there to test _filterOnHost, which was removed. See Part 2.
Depends on D116763
Differential Revision: https://phabricator.services.mozilla.com/D116764
I didn't port _filterOnHost, which searches for history from an engine's domain when its alias is typed. It is no longer relevant: a heuristic alias search result puts the user in search mode.
Depends on D116762
Differential Revision: https://phabricator.services.mozilla.com/D116763
