mirror of
https://github.com/LadybirdBrowser/ladybird
synced 2026-05-01 03:57:15 +02:00
36acd1cf3d
The stacking context tree rebuild had an optimization that skipped rebuilding when a property changed between two values that both create stacking contexts. This is correct for most properties (e.g. opacity 0.5 -> 0.8 doesn't change tree structure), but incorrect for z-index. During tree construction, elements with z-index 0/auto are placed in m_positioned_descendants_and_stacking_contexts_with_stack_level_0, while elements with other z-index values are painted from m_children (negative at step 3, positive at step 9 per CSS 2.1 Appendix E). When z-index changed between non-auto values (e.g. 0 -> 10), the optimization skipped the rebuild, leaving the element in the wrong list and causing it to be painted from both step 8 and step 9. This was visible on pages like shopify.com where elements with transition-all would transition z-index, producing a flood of "Painting commands are recorded twice for stacking context" messages.
19 lines
423 B
Plaintext
19 lines
423 B
Plaintext
Before z-index change:
|
|
AccumulatedVisualContext Tree:
|
|
[1] scroll_frame_id=0 (PaintableWithLines(BlockContainer<PRE>#out))
|
|
|
|
DisplayList:
|
|
SaveLayer@0
|
|
FillRect@1 rect=[8,8 50x50] color=rgb(0, 0, 255)
|
|
Restore@0
|
|
|
|
After z-index change:
|
|
AccumulatedVisualContext Tree:
|
|
[1] scroll_frame_id=0 (PaintableWithLines(BlockContainer<PRE>#out))
|
|
|
|
DisplayList:
|
|
SaveLayer@0
|
|
FillRect@1 rect=[8,8 50x50] color=rgb(0, 0, 255)
|
|
Restore@0
|
|
|