The patch removes the special .webEngine expando and rather use the class to
recognize add engine shortcuts, similarly to how old shortcut buttons did.
It also reuses the add engine handling in SearchOneOffs.js::_on_command rather
than duplicating it.
It is also no more necessary to provide a wrapper around
SearchUIUtils.addOpenSearchEngine because it would only be used once.
Differential Revision: https://phabricator.services.mozilla.com/D112986
Bug 1701193 (D110365) added a bunch of new tests for suggestedIndex results
during view updates, but they all work by doing one search with search
suggestion results followed by another search with URL results. That means they
do not test the part of the view-update logic that allows new suggestions to
replace other types of results once an existing suggestion row is encountered.
This revision adds four new tests that are analogous to the prior tests except
that their first search returns one suggestion followed by URL results, and
their second search returns search suggestions. Therefore they test the
suggestion-replacement logic mentioned above.
The prior tests all use 4 results as the smaller number of results in each test
(with 10 being the larger number). I think it's better to use 5 instead because
that leaves 2 results left over when 1 heuristic and up to 2 suggestedIndex
results are also included, instead of only 1 result left over. That should make
the tests a little more rigorous. Also, 5 is half of 10, so that's a little
nicer too. For consistency I updated the prior tests so that they use 5 instead
of 4 too.
Finally, this revision makes one non-test change. When the update logic
determines whether a new suggestedIndex result is in the right spot, it should
calculate the final index relative to `results.length`, not from the current
number of rows, since `results.length` is the final number of rows once the
update is done and stale rows are removed. The current logic isn't exactly
wrong, but it means that a suggestedIndex result can appear farther down the
view during the update before moving up to its final spot after stale rows are
removed. That can be perceived as flicker, so I think it's better not to show it
at all during the update.
Differential Revision: https://phabricator.services.mozilla.com/D110870
This patch removes the pre-Proton icon and tests. It looks like other changes to icons are just removing the old icons seeing as we're in the 89 Nightly cycle. See D110849 for example.
Differential Revision: https://phabricator.services.mozilla.com/D111155
The issue here is that _rebuildEngineList is being called before updateWebEngines. updateWebEngines initializes _webEngines. When _rebuildEngineList tries to iterate over _webEngines, an exception is thrown.
Differential Revision: https://phabricator.services.mozilla.com/D111113
With bug 1699227 and bug 1701193 fixed, we can now use -1 as the quick suggest
result's suggested index to make it stick to the bottom of the view without any
flickering.
Differential Revision: https://phabricator.services.mozilla.com/D110636
This should fix flickering related to suggested indexes once and for all, knock
on wood. It fixes the view-update logic so that if we encounter a new
suggestedIndex result that can't be placed in the correct spot during the first
loop, we stop trying to update rows at that point and instead mark the remaining
rows as stale. Then we reach the loop that appends the remaining results, and we
append them all starting with the suggestedIndex result. Those results are
hidden at first so that the suggestedIndex result never appears in the wrong
spot.
This fixes bug 1701193 and the flickering problem I noted in bug 1701136. It
also fixes the flicker we have right now with the tab-to-search onboarding
result, where during the view update we briefly have 10 results in the view even
though there should only be 9 since the tab-to-search has a span of 2.
At first I had one big test file for this, but not surprisingly it timed out on
some try machines. So I split it up, moved the new files to a new directory, and
moved the two existing browser_updateRows tests there too.
The new tests all do two searches where the first search returns search
suggestions and the second returns URL results. It would be good to test the
opposite too but this patch is already big enough.
Differential Revision: https://phabricator.services.mozilla.com/D110365
Given the result span problem described in bug 1699211 and bug 1699607,
currently there's no way for quick suggest to accurately specify the last index
as its suggested index.
Differential Revision: https://phabricator.services.mozilla.com/D109571
