Closed
Bug 513949
Opened 15 years ago
Closed 15 years ago
scrollTo on open slows down awesomebar appearance
Categories
(Firefox for Android Graveyard :: General, defect)
Firefox for Android Graveyard
General
Tracking
(Not tracked)
RESOLVED
FIXED
fennec1.0b4
People
(Reporter: Gavin, Assigned: Gavin)
References
Details
Attachments
(1 file)
1.75 KB,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
Testing on the n810, the small code block at:
http://hg.mozilla.org/mobile-browser/annotate/6812a3e70cfd/chrome/content/bindings.xml#l185
seems to take about 500ms of the 600ms spent under openAutocompletePopup() (the check is about 100ms, the scrollTo call about 400ms).
I tested moving it to closePopup(), since taking the hit on close seems better than on open, but strangely enough it seems to run much faster there, which I don't fully understand. It may be that we're trying to open it too early after it's been uncollapsed, and that has odd layout-level implications?
Assignee | ||
Comment 1•15 years ago
|
||
Doesn't seem to make much of a difference if we do it before or after collapsing, in closePopup().
(When I said "much faster", above, I meant that it now takes under 100ms as opposed to the ~500ms - BrowserUI.showToolbar() is more signficant, at aroudn 120ms on average.)
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Attachment #397902 -
Flags: review?(mark.finkle)
Assignee | ||
Updated•15 years ago
|
Summary: scrollToTop slows down awesomebar appearance → scrollTo on open slows down awesomebar appearance
Updated•15 years ago
|
Attachment #397902 -
Flags: review?(mark.finkle) → review+
Assignee | ||
Comment 2•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → B4
You need to log in
before you can comment on or make changes to this bug.
Description
•