Consider to remove DB access in nsNavHistoryResultNode::GetTags()
Categories
(Toolkit :: Places, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox119 | --- | fixed |
People
(Reporter: daisuke, Assigned: daisuke)
References
(Depends on 1 open bug)
Details
(Whiteboard: [sng])
Attachments
(2 files)
This is a follow-up bug of bug 1829581.
As mentioned in phabricator, we shoud consdier to remove nsNavHistoryResultNode::GetTags().
Comment 1•2 years ago
|
||
A little bit off-topic, but trying to keep together some thoughts.
This should be the last main-thread SQL in nsNavHistoryResult apart from the GetQueryResults call in FillChildren, that is used by Refresh(), OpenContainer(), OpenContainerAsync... and GetHasChildren(). The scope is to make only open and refresh operations execute queries, to simplify making those async.
For nsNavHistoryFolderResultNode::GetHasChildren asynchronous may be feasible, we would show no twisties until the querying is done, then invalidateRow in the tree. Though there's a lot of usage of .hasChildren to verify in the treeview, as it may break features.
Or alternatively we may keep a map of bookmark folders in memory, loaded at startup and updated through triggers.
Comment 2•2 years ago
|
||
I started filing Bug 1846461 to start moving some stuff out of the "bookmarks" service (that in reality is pretty much a "SynchronousTagsAsBookmarks" service).
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 3•2 years ago
|
||
| Assignee | ||
Comment 4•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 6•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/99ae6c3bb49d
https://hg.mozilla.org/mozilla-central/rev/2ed041c3a569
Description
•