1806028 - Show more suggestions after the user deletes existing ones [Omnibox]

Status: NEW

(WebExtensions :: General, enhancement, P5)

Description

[Gregory Pappas [:gregp]]

Attachment: chrome_behavior.webm

When an extension provides more suggestions than the limit, we should display them after existing ones get deleted by the user. This is what Chrome does.

Comment 1

[Gregory Pappas [:gregp]]

Attachment: firefox_behavior.webm

Comment 2

[Gregory Pappas [:gregp]]

‍

Comment 3

[Gregory Pappas [:gregp]]

:adw, does urlbar already support something like this (more actual results than visible results) or would it need to be added?

Comment 4

[Drew Willcoxon :adw]

It doesn't support this currently. Urlbar results are fetched and added to the view only on each new search, and a search starts when you click into the urlbar or modify the value in the input.

I can think of a few approaches:

1. Start a new urlbar search when an extension result is blocked. This seems like the simplest approach because it fits into the urlbar architecture pretty easily, but it unnecessarily re-queries providers other than the extension provider, and there may be some danger of latency and UI flicker.
2. Start a new search but only query the extension provider. Currently it's not possible to do this while also retaining the results from the other providers.
3. Instead of starting a new search, fetch more extension results than necessary in the original search and cache them somewhere. Slot them in when a result is blocked. This isn't currently possible either and would probably require modifying the muxer.

I'm curious how Chrome handles this. Their UI in the video looks incredibly fast and responsive. I wonder if they fetch as many suggestions from the extension as possible up front and so they're cached and ready to go when one is deleted, or if they fetch them as needed.

Also, before we started making large changes to support this, I'd be interested in knowing how many users actually use extensions that have deletable results and of those users how many actually do delete results. It seems possible to add telemetry for those things. I would guess it's a small number. That's not necessarily an argument for not doing it but it might be.

Comment 5

[Drew Willcoxon :adw]

The block button is still new and it's only been used on a couple of special one-off results. However, we have plans to add it to all results so that any result can be blocked, or at least results where it's possible [1]. In that world it might make sense to always start a new search when a result is blocked so that the view can remain as full as possible (approach 1 above). Then extension results would get that behavior for free.

[1] Actually the plan is to add a ... button on hover/selection that shows a menu when clicked, and one of the menu items would be a block command.

Comment 6

[Gregory Pappas [:gregp]]

Attachment: janky_chrome.webm

(In reply to Drew Willcoxon :adw from comment #4)

I'm curious how Chrome handles this. Their UI in the video looks incredibly fast and responsive. I wonder if they fetch as many suggestions from the extension as possible up front and so they're cached and ready to go when one is deleted, or if they fetch them as needed.

Certainly the former. I can be reasonably certain of this because resizing the window becomes incredibly janky.

Instead of starting a new search, fetch more extension results than necessary in the original search and cache them somewhere. Slot them in when a result is blocked. This isn't currently possible either and would probably require modifying the muxer.

So, in my head, I'm imagining a new group property ala maxResultCount but something like maxInvisibleOverflowCount which defines the maximum amount of "invisibly overflowed" results. Then, the max-height of urlbar-results is set to match maxResultCount/availableSpan and I add some code somewhere to prevent arrowing down into these invisibly overflowed results and it "just works" with hopefully minimal changes required.

Comment 7

[Gregory Pappas [:gregp]]

Attachment: quick_hack.webm

Quick hack to demo the proposal in comment 6.