Open Bug 1846533 Opened 1 year ago Updated 1 year ago

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)

Firefox 115
defect

Tracking

()

UNCONFIRMED
Performance Impact low

People

(Reporter: iliazeus, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf:responsiveness)

Attachments

(1 file)

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.

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.

Summary: Tab freezes for about 10 seconds when collapsing a <details> that has a huge and deep subtree → Tab freezes for about 10 seconds when collapsing a <details> that has a huge and deep subtree with many nested <details>

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.

Component: Untriaged → Inspector
Product: Firefox → DevTools

Judging by the call stack from the profile, this is more of an `a11y

Component: Inspector → Disability Access APIs
Product: DevTools → Core

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)

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

Blocks: a11yperf
Severity: -- → S3
Performance Impact: --- → ?

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.

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

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

Performance Impact: ? → low
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: