Tab freezes for about 10 seconds when collapsing a <details> that has a huge and deep subtree with many nested <details>
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
Performance Impact | low |
People
(Reporter: iliazeus, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf:responsiveness)
Attachments
(1 file)
(deleted),
text/html
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Steps to reproduce:
When collapsing a <details> element that has a huge and deep child subtree, the tab becomes unresponsive for about 10 seconds.
I have attached an anonymized version of a reproduction page. To reproduce, collapse the outermost (topmost) <details>.
Actual results:
The tab became unresponsive for about 10 seconds - the cursor was not changing when hovering on links; nothing happened when clicked. Visually, the <details> remained opened; however, in the DevTools inspector, the "open" attribute had changed immediately.
During this time, my system monitor was showing 100% utilization of a single processor core.
After about 10 seconds, the <details> has collapsed, and the tab became responsive again.
I have uploaded a profile of this: https://share.firefox.dev/3ONolcd
Expected results:
The tab should not have frozen for so long.
Reporter | ||
Comment 1•1 year ago
|
||
I should have mentioned: the <details> has a lot of nested <details> inside it. When I change the nested <details> to simple <span> elements, the tab no longer freezez.
Reporter | ||
Updated•1 year ago
|
Comment 2•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'DevTools::Inspector' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Reporter | ||
Comment 3•1 year ago
|
||
Judging by the call stack from the profile, this is more of an `a11y
Reporter | ||
Comment 4•1 year ago
|
||
Updated the (probable) Product and Component based on the profile call stack.
(P.S. is there a "remove comment" feature? the previous one was mistyped)
Comment 5•1 year ago
|
||
I'm sure I've seen AllChildrenIterator show up for an a11y performance problem in the past, but I can't remember where right now...
Comment 6•1 year ago
|
||
Out of interest, are you running an accessibility tool of some sort? I'm curious as to why accessibility is being enabled on your system in the first place.
Reporter | ||
Comment 7•1 year ago
|
||
(In reply to James Teh [:Jamie] from comment #6)
Out of interest, are you running an accessibility tool of some sort? I'm curious as to why accessibility is being enabled on your system in the first place.
I did not enable any accessibility tools myself. And Firefox was running in "troubleshooting mode" when I recorded the profile.
I use it with KDE on Arch Linux though - maybe it has some accessibility features enabled by default there? Not sure how to check.
Comment 8•1 year ago
|
||
The Performance Impact Calculator has determined this bug's performance impact to be low. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.
Impact on site: Causes noticeable jank
Configuration: Specific but common
Websites affected: Rare
Description
•