Awesomebar slow interaction in a well-used profile

RESOLVED DUPLICATE of bug 1356532

Status

()

defect
RESOLVED DUPLICATE of bug 1356532
2 years ago
2 years ago

People

(Reporter: yoasif, Unassigned)

Tracking

(Depends on 1 bug)

57 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

2 years ago
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
Reporter

Updated

2 years ago
Component: Untriaged → Address Bar
Reporter

Comment 1

2 years ago
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
Reporter

Updated

2 years ago
Reporter

Updated

2 years ago
Reporter

Updated

2 years ago
Keywords: regression
Reporter

Updated

2 years ago
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
Reporter

Updated

2 years ago
Status: RESOLVED → UNCONFIRMED
Keywords: regression
Resolution: WORKSFORME → ---
Reporter

Comment 2

2 years ago
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.
Reporter

Updated

2 years ago
Reporter

Comment 3

2 years ago
[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.
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
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.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1356532
You need to log in before you can comment on or make changes to this bug.