Closed Bug 499808 Opened 11 years ago Closed 11 years ago

Long pause before first awesomebar results

Categories

(Toolkit :: Places, defect, P2)

All
Windows CE
defect

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: vlad, Assigned: Dolske)

Details

(Whiteboard: [nv])

Attachments

(1 file)

Placeholder bug for now.  Need to profile to figure out what's going on here, and what we can do about it.
This seems to be largely fixed now. Testing with my daily-browsing profile (45MB places.sqlite), searches are reasonably quick and responsive, and don't interfere too much with typing.

The only somewhat annoying thing is that there's a longish pause before results appear. The browser.urlbar.delay pref is currently set to 1000ms (desktop default is 50). 50 seems too low, but 250 made it faster without seeming to interfere with typing. (The first results still take a second or two to show up, that just might be the current cost of searching on a slow device?)

I'd suggest we bump the pref down to 250ms, and call this bug fixed.
Attached patch Patch v.1Splinter Review
Assignee: vladimir → dolske
Attachment #399890 - Flags: review?(vladimir)
Morphing to the current issue; the original concern was likely fixed by bug 455555 and other Places perf work.
Summary: Awesomebar is really slow on Windows CE → Long pause before first awesomebar results
Attachment #399890 - Flags: review?(vladimir) → review+
Pushed http://hg.mozilla.org/mozilla-central/rev/7833f0dd30af
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.