This is a follow up to D161866 and effectively reverts and replaces it with a
different approach. Please see bug 1800810 for background. In short, engagement
telemetry should be based on the result that's visible in the view, not on the
result the provider added last.
D161866 fixed the case where the last-added result is in the view but hidden.
There's another case we need to handle, when the last-added result is not in the
view at all. That can happen when you type something and hit enter really
quickly, before the view can update. I was able to trigger it several times.
When that happens, there are two possibilities:
No quick suggest result is visible in the view.
result.rowIndex is its
initial value of -1, so we record an engagement for a result that is not
visible and that doesn't have a valid index.
A quick suggest result from a previous query is visible in the view. Here
result.rowIndex is -1 so we record an engagement for a result that is
not visible and that doesn't have a valid index, and we miss recording an
engagement for the result that's actually visible.
Right now it's not easy to fix this inside the provider because providers don't
know anything about the view(s). I could record this telemetry in the view but
that's not its role. I think it makes sense to include the view in the query
context, so that's what this does. I added
view.visibleResults to make getting
the visible results easy.
Daisuke's new Glean telemetry in D160193 uses
context.results, which has this
same problem of not being based on actually visible results. We'll need to use
context.view.visibleResults there too, and there may be other existing cases