Bug 1800184 fixed the case where a quick suggest result is in the view but hidden, but I found one more case it didn't fix: The user can pick a result (i.e., complete an engagement) after the provider `add()`'ed it but before it's added to the view. That means we can end up recording telemetry for results that aren't actually visible in the view, since the telemetry is based on `_resultFromLastQuery`, which is simply the result the provider added last. In short we need to base engagement telemetry on the result that's visible in the view, not on the result the provider added last.
Bug 1800810 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Bug 1800184 fixed the case where a quick suggest result is in the view but hidden, but I found one more case it didn't fix: The user can pick a result (i.e., complete an engagement) after the provider `add()`'ed it but before it's added to the view. [Edit: This sentence is confusing. What I mean is: After the quick suggest provider adds a result to the context but before that result is shown in the view, the user can pick another unrelated result in the view.] That means we can end up recording telemetry for results that aren't actually visible in the view, since the telemetry is based on `_resultFromLastQuery`, which is simply the result the provider added last. In short we need to base engagement telemetry on the result that's visible in the view, not on the result the provider added last.