Closed Bug 513949 Opened 10 years ago Closed 10 years ago
To on open slows down awesomebar appearance
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?
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)
Summary: scrollToTop slows down awesomebar appearance → scrollTo on open slows down awesomebar appearance
Attachment #397902 - Flags: review?(mark.finkle) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → B4
You need to log in before you can comment on or make changes to this bug.