Closed Bug 1935876 Opened 2 months ago Closed 28 days ago

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)

defect

Tracking

()

RESOLVED FIXED
136 Branch
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.

Attached file about:support
Component: General → Firefox View
Summary: Sorting by site takes 15 seconds each time (spends all the time in nsIContent::GetContainingShadow around L10n) → Sorting by site janks the parent-process for 15 seconds each time (spends all the time in nsIContent::GetContainingShadow around L10n)
See Also: → 1935877

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?)

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.

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

Severity: -- → S3
Priority: -- → P3
Whiteboard: [fidefe-firefox-view]

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.)

Flags: needinfo?(mayankleoboy1)

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 )

Flags: needinfo?(mayankleoboy1)

(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 and Profiled Threads File IO

(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 and Profiled Threads File IO

https://share.firefox.dev/3ZDhkyL (sqldb + I/O)

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.

Duplicate of this bug: 1935877

Hey Mark, I see you have a WIP patch - can I assign this bug to you?

Flags: needinfo?(mstriemer)
Assignee: nobody → mstriemer
Attachment #9443879 - Attachment description: WIP: Bug 1935876 - Create a single panel-list for fxview history pane → Bug 1935876 - Create a single panel-list for fxview history pane r?#fxview-reviewers
Status: NEW → ASSIGNED
Flags: needinfo?(mstriemer)
Pushed by mstriemer@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d342dabbf522 Create a single panel-list for fxview history pane r=fxview-reviewers,jsudiaman
Status: ASSIGNED → RESOLVED
Closed: 28 days ago
Resolution: --- → FIXED
Target Milestone: --- → 136 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: