Also, this is more of an engineering consideration rather than UX, but this bug would be considerably easier to implement if we dedupe the suggestion rather than the search history result. History results are `PROVIDER_TYPE.IMMEDIATE` whereas suggestions are `PROVIDER_TYPE.NETWORK`. The search history result arrives at the muxer first. Since the search suggestion arrives later and has a different position in the results, we get flickering if we remove the search history result in favour of the suggestion. There's no flickering if we simply don't show the suggestion if there's already an "identical" search history result. My current patch just shows whichever result arrives first and doesn't show the second one. In virtually all (all?) cases, this means we show the search history result and not the suggestion. Marco, do you have any thoughts on this?
Bug 1626946 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Also, this is more of an engineering consideration rather than UX, but this bug would be considerably easier to implement if we remove the suggestion rather than the search history result. History results are `PROVIDER_TYPE.IMMEDIATE` whereas suggestions are `PROVIDER_TYPE.NETWORK`. The search history result arrives at the muxer first. Since the search suggestion arrives later and has a different position in the results, we get flickering if we remove the search history result in favour of the suggestion. There's no flickering if we simply don't show the suggestion if there's already an "identical" search history result. My current patch just shows whichever result arrives first and doesn't show the second one. In virtually all (all?) cases, this means we show the search history result and not the suggestion. Marco, do you have any thoughts on this?