1627672 - Create a Search Tip with download progress for when an update is still downloading

Status: NEW

(Firefox :: Address Bar, enhancement, P3)

Description

[Harry Twyford]

+++ This bug was initially created as a clone of Bug #1625241 +++

We are going to explore a new Search Tip that has some kind of download progress indicator to cover the case when a browser update is still downloading/staging.

This bug will initially cover prototyping the functionality, then we'll pass it over to UX and Content Strategy to come up with a final design/strings.

Comment 1

[Harry Twyford]

AppUpdater.jsm offers a listener with download progress, so the challenge in this bug is updating the Search Tip in-place. There are a few ways to accomplish this:

1. Pass a callback from the provider to the front-end. This isn't safe.
2. Register the AppUpdater listener with UrlbarInput and run a new query when we have new download progress information. This is expensive, descopes updating functionality from UrlbarProviderInterventions, and runs the risk of results disappearing or being in a new order when the new query is returned.
3. Add a new parameter to UrlbarProvider.startQuery: requestUpdate. This would be a callback passed to providers from UrlbarProvidersManager. Providers could request they be re-queried and provide a new set of results. In this case, UrlbarProviderSearchTips would provide an updated tip with up-to-date download progress information. Once UrlbarProvidersManager has the updated results, it could request that UrlbarView run them through _updateResults. This means that whether an update is requested is still scoped to the provider, but UrlbarProvidersManager could still decline the request or delay the update, making this safer. An update request would require that all results from that provider be updated. This removes some flexibility but is ultimately more reliable. We don't have to worry about matching up a single updated result with whatever index it was assigned in UrlbarView. If the provider has one result in the view and the updateRequest contains one result, we update the one result in the view. If the provider has six results in the view and the updateRequest contains ten results, we just update the six results in the view with the first six results in the updateRequest. If the provider has no results in the view, we do nothing with the updateRequest, so this couldn't be used by a provider to bypass the muxer's decision.

Drew, does (3) seem like a reasonable approach?

Comment 2

[Mike de Boer [:mikedeboer]]

At some point we also need to take a serious look at the value of having this part of an intervention, since it's very interstitial in nature. IMHO, I don't think that an intervention should be 'live'; it should show an accurate-as-possible representation of the browser state in reaction to a user-initiated query. Just like any other result, really.

Comment 3

[Drew Willcoxon :adw]

Is this something that Verdi requested? I'm guessing so, but if not then I'm not sure we should spend time on it, to Mike's point. It is interesting to think about dynamic/updating results, though.

One thing that seems challenging to me is managing the lifetime of the "downloading" result. We would want to add an AppUpdater listener when the result is first shown. If the result remains shown when the download finishes, then OK. But what if the result goes away first (either because the view was closed or a new search started)? To your suggestion #3, the provider would call requestUpdate when its AppUpdater listener is called with the new progress info, right? But how would the provider know when to stop calling requestUpdate if the result went away before the download finished? What if the download takes a long time to finish? We could just say the provider keeps its AppUpdater listener and continues notifying the providers manager until the download finishes, and then the providers manager or muxer or view just ignores the updates, but ideally the provider would be able to stop listening to AppUpdater and free up resources once it no longer needs to.

I do like your idea of having requestUpdate though since it's analogous to the add callback the manager passes to providers' startQuery. But I would suggest that the update mechanism be based on result IDs instead of replacing all the provider's results wholesale. So if the provider has a result it may want to update, it would include an ID in the initial result, and then it would pass the updated result and the ID to requestUpdate. Then the manager/muxer/view would look up the result by ID. There might need to be some notion of "session" ID too (or query ID) so that we don't mistakenly update a result of the same ID but in a subsequent query.

That might help solve the lifetime question too. The provider could pass a callback to the manager that the manager (or someone) would call once the result goes away or isn't visible anymore. (Or it could just be a method on the provider.) The provider would provide the result ID along with the callback, and then the callback would include this ID so that the provider knows which result went away. Query IDs would be necessary here too probably.