Closed Bug 1373821 Opened 7 years ago Closed 6 years ago

Browser getting unresponsive after clicking on tag/folder in bookmarks bar

Categories

(Firefox :: Bookmarks & History, defect, P3)

56 Branch
defect

Tracking

()

RESOLVED FIXED
Firefox 61
Tracking Status
firefox56 --- affected

People

(Reporter: philipp, Assigned: mak)

References

(Blocks 1 open bug)

Details

(Keywords: perf, Whiteboard: [fxsearch])

Version 	56.0a1
Build-ID 	20170616030207
User-Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0

i was clicking on a tag/folder in my bookmarks toolbar folder containing around 10 bookmarks. before the drop-down with the results appeared, the browser ui hung for about 10 seconds and windows' program not responding appeared in the titlebar.

this is a snapshot taken with the gecko profiler: http://bit.ly/2rFo2SJ
Component: Untriaged → Bookmarks & History
(In reply to [:philipp] from comment #0)
> this is a snapshot taken with the gecko profiler: http://bit.ly/2rFo2SJ

Florian, can you look into this profile?
Flags: needinfo?(florian)
(In reply to Panos Astithas [:past] (56 Regression Engineering Owner) (please ni?) from comment #1)
> (In reply to [:philipp] from comment #0)
> > this is a snapshot taken with the gecko profiler: http://bit.ly/2rFo2SJ
> 
> Florian, can you look into this profile?

Main thread I/O in nsNavBookmarks::GetDescendantFolders at http://searchfox.org/mozilla-central/rev/6326724982c66aaeaf70bb7c7ee170f7a38ca226/toolkit/components/places/nsNavBookmarks.cpp#1067

Blocking the main thread for at least 3.2s (and more likely 12.7s, but the profile buffer wasn't large enough to capture samples during all of the main thread jank).

I've already seen main thread I/O block for more than 30s a couple times (typically I had Windows Defender running a background scan of the whole disk when it happened).
Flags: needinfo?(florian)
GetDescendantFolders is indeed a sync API we use when querying in very specific cases, basically for queries specifying both a folder=N and other conditions, then we want to pick all the bookmarks below that folder in the tree.

For tags we should not go through it, but we wrongly do.
It's sort of an edge case, but probably bad for tag addicted users.

I think this would be fixed by bug 1293445. We could even fix it earlier with a workaround if necessary.
Depends on: 1293445
Priority: -- → P2
Whiteboard: [fxsearch]
Priority: P2 → P3
Blocks: placesAsyncBookmarks
No longer blocks: 1309930
This should be gone with the fix for bug 1293445. I'll file a separate bug to completely remove GetDescendantFolders, I think we can replace it with a recursive CTE subquery.
Assignee: nobody → mak77
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
You need to log in before you can comment on or make changes to this bug.