_maybeToggleBookmarkToolbarVisibility initializes places early when there's no need
Categories
(Firefox :: Bookmarks & History, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox72 | --- | fixed |
People
(Reporter: Gijs, Assigned: mconley)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fxperf:p2])
Attachments
(1 file)
This gets run on a clean profile only, but unless migration ran, enterprise policies ran, or the user copied files into the dir, we shouldn't have any bookmarks anyway. Profile: https://perfht.ml/2X7VIsA
We could maybe use Cm.isServiceInstantiatedByContractID
to check if the bookmarks service has been created, and if not, delay doing this work until an idle task after the window has been shown. Given that this only affects new profiles, it seems more important to bring the window up ASAP.
Reporter | ||
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Does this just kick the can down the road, or do we know this is all it would take to delay initializing the bookmarks service until an arbitrarily later time?
Comment 2•6 years ago
|
||
We have test coverage that ensures the bookmarks service isn't started before handling user events: https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/browser/base/content/test/performance/browser_startup.js#100
At https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/browser/base/content/test/performance/browser.ini#8-10 a pref is set so that we skip the migration code path when running the browser_startup.js test.
(In reply to Doug Thayer [:dthayer] from comment #1)
do we know this is all it would take to delay initializing the bookmarks service until an arbitrarily later time?
Per the above two points, I'm fairly confident the answer is 'yes'.
Comment 3•6 years ago
|
||
[fxperf:p2] then, as it could have a substantial impact on first profile startup for not a ton of work.
Comment 4•6 years ago
|
||
I don't recall if this was also for the Profile Reset case, where we will copy over places.sqlite, and we want to show the toolbar. Do we restore toolbar status on Profile Reset?
Updated•6 years ago
|
Reporter | ||
Comment 5•6 years ago
|
||
(In reply to Marco Bonardo [::mak] from comment #4)
I don't recall if this was also for the Profile Reset case, where we will copy over places.sqlite, and we want to show the toolbar. Do we restore toolbar status on Profile Reset?
We don't, but it seems OK to do so lazily in that one case (or, if we're really concerned about that, to add code to check for this as part of the migration inside fx profile reset)
Assignee | ||
Comment 6•6 years ago
|
||
(In reply to :Gijs (he/him) from comment #0)
We could maybe use
Cm.isServiceInstantiatedByContractID
to check if the bookmarks service has been created, and if not, delay doing this work until an idle task after the window has been shown. Given that this only affects new profiles, it seems more important to bring the window up ASAP.
If we're willing to do the work of updating the visibility of the bookmarks toolbar after the UI has painted in the common case, maybe we're willing to do it even if the bookmarks service has been created.
So maybe we can just unilaterally delay _maybeToggleBookmarkToolbarVisibility
from running until, say, Places has already initted.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
This causes BrowserGlue to wait until Places has notified that it's initted before checking
to see whether or not the Bookmarks Toolbar should be shown.
Also, if it turns out that the Bookmarks Toolbar is shown, we now use CustomizableUI to do
this, which means that the Bookmarks Toolbar will be made visible on all windows after the
check is run - not just new windows.
Assignee | ||
Comment 8•5 years ago
|
||
Assignee | ||
Comment 9•5 years ago
|
||
ni?ing mkaply for MattN's question in https://phabricator.services.mozilla.com/D51701#1569604
Comment 11•5 years ago
|
||
Comment 12•5 years ago
|
||
bugherder |
Description
•