Sorting by site janks the parent-process for 15 seconds each time (spends all the time in nsIContent::GetContainingShadow around L10n)
Categories
(Firefox :: Firefox View, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox136 | --- | fixed |
People
(Reporter: mayankleoboy1, Assigned: mstriemer)
References
Details
(Whiteboard: [fidefe-firefox-view])
Attachments
(2 files)
Click on that Firefox view button
The View page will open. By default the history are sorted by date
Click on "sort by site"
AR: https://share.firefox.dev/41pzztZ , https://share.firefox.dev/4ijcFut , https://share.firefox.dev/4g1oMe4
ER: instant
Another problem is that the sort order persists each time you open Firefox View. So each time you click on that View button, the page will take 15 seconds.
Reporter | ||
Comment 1•2 months ago
|
||
Reporter | ||
Updated•2 months ago
|
Reporter | ||
Updated•2 months ago
|
Comment 2•2 months ago
•
|
||
Please don't file multiple bugs for the same issue; your first issue should have all relevant details to help us with an initial investigation. See my comment on bug 1935877.
We removed the history row limit in 132 (see bug 1914138), but if you're only seeing this issue now in 135 this makes me wonder if something else is going on. We haven't made any change with regards to sorting logic recently. Can you confirm if you also experienced this with version 132?
cc'ing Markus and Marco for visibility and if they have any thoughts. The easiest thing would be to put a limit back in with a limit of entries (maybe 3000?)
Reporter | ||
Comment 3•2 months ago
|
||
I had removed the view icon from my toolbar whwn it first appeares months back, and never used it.
I only used this feature yesterday because the View icon wouldn't stay removed from the toolbar.
Comment 4•2 months ago
|
||
from about:support it looks like this is not a super large history, about 100k entries. most of the time seems to be spent in shadow DOM?
doesn't look like we're spending a lot of time in Places, though to check I/O it would be necessary to get a performance profile including custom sqldb
thread name and Profiled Threads File IO
Updated•2 months ago
|
Updated•2 months ago
|
Comment 5•2 months ago
|
||
The profile is from a Windows machine. Mayank, I don't suppose you have access to a mac and can check if you see the same problem? Trying to confirm something. :-)
(I don't see the same issue on a mac, and the inverted stacks from comment 0 all go through panel-list access key formatting code, which surprises me - certainly on macOS the access keys are not visible so I wonder if this is ultimately platform-specific.)
Reporter | ||
Comment 6•2 months ago
•
|
||
I only have a Win11 machine. Any profile with specific threads, or any logging I can provide?
(If you send me a mac machine, I can test on that :D )
Comment 7•2 months ago
|
||
(In reply to Mayank Bansal from comment #6)
I only have a Win11 machine. Any profile with specific threads, or any logging I can provide?
Marco asked in comment 4:
doesn't look like we're spending a lot of time in Places, though to check I/O it would be necessary to get a performance profile including custom
sqldb
thread name andProfiled Threads File IO
Reporter | ||
Comment 8•2 months ago
|
||
(In reply to :Gijs (he/him) from comment #7)
Marco asked in comment 4:
doesn't look like we're spending a lot of time in Places, though to check I/O it would be necessary to get a performance profile including custom
sqldb
thread name andProfiled Threads File IO
https://share.firefox.dev/3ZDhkyL (sqldb + I/O)
Comment 9•2 months ago
|
||
There's 2 potentially "large" reads from the db, just before the janks. It sounds like we're handing off results to the UI, and I don't think there's a database/IO bottleneck here.
Assignee | ||
Comment 10•2 months ago
|
||
Comment 12•1 month ago
|
||
Hey Mark, I see you have a WIP patch - can I assign this bug to you?
Updated•1 month ago
|
Assignee | ||
Updated•1 month ago
|
Comment 13•28 days ago
|
||
Comment 14•28 days ago
|
||
bugherder |
Description
•