Open
Bug 1602260
Opened 6 years ago
Updated 3 years ago
hiding large number of sibling elements with CSS selector slow in nsBlockFrame::DoRemoveFrameInternal
Categories
(Core :: Layout: Block and Inline, defect, P3)
Tracking
()
NEW
People
(Reporter: cpartiot, Unassigned)
Details
(Keywords: perf)
Attachments
(1 file)
|
538.40 KB,
text/html
|
Details |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0
Steps to reproduce:
- create a large number of
<div>s - append them on an elements in DOM
- add a CSS rules to hide all of them individually (
.myElement > div {display: none})
example: https://codepen.io/yukulele/pen/NWPGErM
Actual results:
- Firefox freeze for a few seconds before update dom
- tab sometime crash
Expected results:
- redraw should be faster
- tab should not crash for CSS
|
||
Updated•6 years ago
|
|
|
||
Comment 1•6 years ago
|
||
I can reproduce the performance issue on Nightly73.0a1 Windows10.
https://perfht.ml/347OEim
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Comment 2•6 years ago
|
||
Seems like nsBlockFrame::DoRemoveFrameInternal is hitting a O(n^2), probably when looking for the line to remove the frame from?
Component: Layout → Layout: Block and Inline
|
||
Comment 3•6 years ago
|
||
The priority flag is not set for this bug.
:dbaron, could you have a look please?
For more information, please visit auto_nag documentation.
Flags: needinfo?(dbaron)
Flags: needinfo?(dbaron)
Priority: -- → P3
Summary: css performance: hide a lot of elements → hiding large number of sibling elements with CSS selector slow in nsBlockFrame::DoRemoveFrameInternal
|
||
Updated•3 years ago
|
Severity: normal normal → S3 S3
You need to log in
before you can comment on or make changes to this bug.
Description
•