1399007 - Awesomebar slow interaction in a well-used profile

Status: RESOLVED DUPLICATE of bug 1356532

(Firefox :: Address Bar, defect)

Description

[Asif Youssuff]

Attachment: Peek 2017-09-12 00-30.mp4

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170912013600

Steps to reproduce:

0. Have a 5.2 mb places.sqlite file (my profile has been through multiple refreshes, so it's "clean", but is well-used. 

1. Type Ctrl-L to activate awesomebar
2. type in "fi" and immediately press down arrow on keyboard
3. hit escape once second entry in awesomebar is highlighted

(repeat)


Actual results:

It takes half a second to a second for the UI to highlight the second awesomebar result. 


Expected results:

Interaction should happen as close to instant as possible; this is core browser functionality and not related to web page rendering -- this should be *fast*. 

I had a single window open for this exercise and no open tabs other than a server not found Firefox page. 

See attachment for a quick video demonstrating the issue. 

Profile: https://perf-html.io/public/10a7631f41070aeef8f6ade817aef57caf66ff8b/calltree/?hiddenThreads=&thread=44&threadOrder=0-1-2-3-4-5-6-7-8-9-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-31-32-33-34-35-36-37-38-39-40-41-42-43-44-45-46-47-48-49-50-51-52-53-54-55-56-57-58-59-60-61-62-63-64-65-66-67-68-69-70-71-72-73-74-75-76-77-78-79-80-81-82-83-84-85-86-87-88-89-10

Comment 1

[Asif Youssuff]

Looks like this is a regression.

11:55.16 INFO: No more inbound revisions, bisection finished.
11:55.16 INFO: Last good revision: 556f19ef392ac2d9aac579864e2179d6c1d464e8
11:55.16 INFO: First bad revision: 5845151f1a2cd00957fdd48e204542ccbdfaba1e
11:55.16 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=556f19ef392ac2d9aac579864e2179d6c1d464e8&tochange=5845151f1a2cd00957fdd48e204542ccbdfaba1e

Comment 2

[Asif Youssuff]

Ignore my last comment about the regression range; my feeling now is that somehow a web page or pages are causing this to be slow. Reopening in the hopes that someone can study the profile and understand what is going on.

Comment 3

[Asif Youssuff]

[Tracking Requested - why for this release]:

Users affected will be long standing users of Firefox any time they use the awesomebar (multiple times a session).
The number of users affected could be in the millions. 

To clarify my two last comments on this ticket - I am not sure it is a regression, because it seems like it can occur as early as 55 (where I started my regression range check). Also, it's not another process running at the same time, because I forgot that my profile was done in a session with no other tabs open.

Comment 4

[Marco Bonardo [:mak]]

This bug as is not actionable yet, and we don't have signs for this to happen commonly in the wild based on telemetry.
We should surely investigate why it's slow in your case, but unless it's  a regression in 57, it doesn't need to be tracked for this specific version.

It's likely that in general having a busy system or an heavy page may slowdown the search, in the end resources are always shared.
Note also that the awesomebar when you press DOWN, must wait for the next result to come, to be able to serve that down action, and if that result doesn't exist, or has a very low score, it may take a few ms before we give up. I'm not sure how much is a common case though.

Based on the profile looks like bug 1356532 and bug 1391293 may help, I see some time spent on layout reflows there

Comment 5

[Florian Quèze [:florian]]

67% of the jank time in the profile from comment 0 is spent in _handleOverflow, so this is definitely bug 1356532 we are seeing here.