can we avoid invalidating the entire tree in nsAutocompleteController::ProcessResult()? spun off from bug #389593 comment #4: gavin wrote: Seems like we invalidate the entire tree in ProcessResult(), ideally in the incremental search case we could invalidate only the rows that were added (which in most cases won't even be drawn because they're scrolled off the screen). I think the best way to do this would be to expose additional invalidate*() variants on nsIAutoCompletePopup, implement them in autocomplete.xml (which just forwards to the tree's boxobject), and then have the autocomplete controller invalidate only the parts that have changed. This might be tricky because the controller can't know how the two sets of results differ, because the history service nsIAutocompleteSearch impl just calls onSearchResult multiple times with a new autocomplete result each time, as far as I can tell, but something to look at in a followup bug, for sure (I think it would also benefit other autocomplete consumers, and probably fix bug 391889).

see also dietrich comment at https://bugzilla.mozilla.org/show_bug.cgi?id=389491#c32

adding tsnap to the whiteboard to get this visible, since it affects our ability to make things appear responsive in a reasonable way.

A work in progress. I am not presently sure how to handle invalidateRow for the richlist popup, which is sadly what the location bar uses. The other one is super easy to do!

I don't even know if this works, but I'm uploading a checkpoint. I have figured out how to invalidate just a row with the richlistbox implementation.

I am not actually sure that this is even needed. The richlistbox autocomplete smartly updates things. The tree autocomplete doesn't so much though, so it might be needed there.

This sounds like an opportunistic perf/responsiveness win, so definitely wanted if there's a real win to be had - but not something we'd hold the release for.

tree autocomplete has gone.