Closed
Bug 898215
Opened 12 years ago
Closed 7 years ago
New windows are painted with a default search provider icon/text and then repainted with the current engine
Categories
(Firefox :: Search, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: MattN, Unassigned)
Details
(Keywords: perf)
Attachments
(2 files)
While using Bas' Moz2d browser recorder, one of the more obvious inefficiencies is that upon window creation, we first draw the search box in it's default state and then set the placeholder and icon for the current engine. I don't know the magnitude of the real-world impact.
I'm not sure if this is a regression from the async initialization of the search service or not but that seems likely. If that landing didn't regress talos then perhaps this difference is negligible.
If this is a problem worth fixing we should try to have the search box setup before first paint to avoid the repaint. One possible solution is to use XUL persistence to remember the icon and placeholder text.
Reporter | ||
Comment 1•12 years ago
|
||
Filling the contents of the search box with the correct provider is one of the last steps of painting in my recording on Windows 7 so this may affect the perceived startup completion time.
Comment 2•12 years ago
|
||
Caching the icon somehow seems reasonable, but search service init is inherently async (and will be more so after bug 862179), so we can't block the first paint on getting the icon from there.
Comment 3•7 years ago
|
||
We stopped showing this search plugin icon in bug 1088660 for Firefox 34, and new window opening is now covered by flicker tests, as of bug 1421456.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•