Loading
Bug 1744367 - Part 1: Always make room for the heuristic result when maxRichResults > 0. r=harry
The problem (as described in the bug) is that the user's `maxRichResults` is 3 and the tab-to-search provider returns two onboarding results, so when the muxer subtracts the total result span (4) of those two results from the available span (3), there's no room left for the heuristic. On top of that, there's the usual async nature of fetching results where the muxer's `sort()` gets called multiple times per query, so the heuristic can briefly appear before the TTS results arrive and push it out. This part-1 patch forces the available result span to be no smaller than the largest heuristic result span when `maxRichResults` is positive. That way a heuristic will always be included regardless of whatever suggested-index results are present or whatever result spans the heuristic and suggested-index results have. This also fixes a potential other problem when the heuristic is hidden but has a result span larger than 1. Currently we just increment the available span to compensate, but it should be increased by the heuristic's result span. For both of the two fixes mentioned above, this patch uses the largest heuristic result span when there are multiple heuristics. The muxer can't know which heuristic will end up winning in the end at the time it needs to make these adjustments to the available span, so it could be the case that the largest heuristic span is not the span of the final heuristic. But in that case the only consequence is that the list of results will have fewer results than necessary. Differential Revision: https://phabricator.services.mozilla.com/D134771