LibWeb/Ladybird: Scrolling the DOM inspector's properties table is broken #22534
Labels
bug
Something isn't working
Comments
|
This is caused by ac6b3c9 |
kalenikaliaksandr
added a commit
to kalenikaliaksandr/serenity
that referenced
this issue
Jan 28, 2024
With this change, clip rectangles for boxes with hidden overflow or the clip property are no longer calculated during the recording of painting commands. Instead, it has moved to the "pre-paint" phase, along with the assignment of scrolling offsets, and works in the following way: 1. The paintable tree is traversed to collect all paintable boxes that have hidden overflow or use the CSS clip property. For each of these boxes, the "final" clip rectangle is calculated by intersecting clip rectangles in the containing block chain for a box. 2. The paintable tree is traversed another time, and a clip rectangle is assigned for each paintable box contained by a node with hidden overflow or the clip property. This way, clipping becomes much easier during the painting commands recording phase, as it only concerns the use of already assigned clip rectangles. The same approach is applied to handle scrolling offsets. Also, clip rectangle calculation is now implemented more correctly, as we no longer stop at the stacking context boundary while intersecting clip rectangles in the containing block chain. Fixes: SerenityOS#22932 SerenityOS#22883 SerenityOS#22679 SerenityOS#22534
kalenikaliaksandr
added a commit
to kalenikaliaksandr/serenity
that referenced
this issue
Jan 28, 2024
With this change, clip rectangles for boxes with hidden overflow or the clip property are no longer calculated during the recording of painting commands. Instead, it has moved to the "pre-paint" phase, along with the assignment of scrolling offsets, and works in the following way: 1. The paintable tree is traversed to collect all paintable boxes that have hidden overflow or use the CSS clip property. For each of these boxes, the "final" clip rectangle is calculated by intersecting clip rectangles in the containing block chain for a box. 2. The paintable tree is traversed another time, and a clip rectangle is assigned for each paintable box contained by a node with hidden overflow or the clip property. This way, clipping becomes much easier during the painting commands recording phase, as it only concerns the use of already assigned clip rectangles. The same approach is applied to handle scrolling offsets. Also, clip rectangle calculation is now implemented more correctly, as we no longer stop at the stacking context boundary while intersecting clip rectangles in the containing block chain. Fixes: SerenityOS#22932 SerenityOS#22883 SerenityOS#22679 SerenityOS#22534
kalenikaliaksandr
added a commit
to kalenikaliaksandr/serenity
that referenced
this issue
Jan 28, 2024
With this change, clip rectangles for boxes with hidden overflow or the clip property are no longer calculated during the recording of painting commands. Instead, it has moved to the "pre-paint" phase, along with the assignment of scrolling offsets, and works in the following way: 1. The paintable tree is traversed to collect all paintable boxes that have hidden overflow or use the CSS clip property. For each of these boxes, the "final" clip rectangle is calculated by intersecting clip rectangles in the containing block chain for a box. 2. The paintable tree is traversed another time, and a clip rectangle is assigned for each paintable box contained by a node with hidden overflow or the clip property. This way, clipping becomes much easier during the painting commands recording phase, as it only concerns the use of already assigned clip rectangles. The same approach is applied to handle scrolling offsets. Also, clip rectangle calculation is now implemented more correctly, as we no longer stop at the stacking context boundary while intersecting clip rectangles in the containing block chain. Fixes: SerenityOS#22932 SerenityOS#22883 SerenityOS#22679 SerenityOS#22534
kalenikaliaksandr
added a commit
to kalenikaliaksandr/serenity
that referenced
this issue
Jan 28, 2024
With this change, clip rectangles for boxes with hidden overflow or the clip property are no longer calculated during the recording of painting commands. Instead, it has moved to the "pre-paint" phase, along with the assignment of scrolling offsets, and works in the following way: 1. The paintable tree is traversed to collect all paintable boxes that have hidden overflow or use the CSS clip property. For each of these boxes, the "final" clip rectangle is calculated by intersecting clip rectangles in the containing block chain for a box. 2. The paintable tree is traversed another time, and a clip rectangle is assigned for each paintable box contained by a node with hidden overflow or the clip property. This way, clipping becomes much easier during the painting commands recording phase, as it only concerns the use of already assigned clip rectangles. The same approach is applied to handle scrolling offsets. Also, clip rectangle calculation is now implemented more correctly, as we no longer stop at the stacking context boundary while intersecting clip rectangles in the containing block chain. Fixes: SerenityOS#22932 SerenityOS#22883 SerenityOS#22679 SerenityOS#22534
kalenikaliaksandr
added a commit
to kalenikaliaksandr/serenity
that referenced
this issue
Jan 28, 2024
With this change, clip rectangles for boxes with hidden overflow or the clip property are no longer calculated during the recording of painting commands. Instead, it has moved to the "pre-paint" phase, along with the assignment of scrolling offsets, and works in the following way: 1. The paintable tree is traversed to collect all paintable boxes that have hidden overflow or use the CSS clip property. For each of these boxes, the "final" clip rectangle is calculated by intersecting clip rectangles in the containing block chain for a box. 2. The paintable tree is traversed another time, and a clip rectangle is assigned for each paintable box contained by a node with hidden overflow or the clip property. This way, clipping becomes much easier during the painting commands recording phase, as it only concerns the use of already assigned clip rectangles. The same approach is applied to handle scrolling offsets. Also, clip rectangle calculation is now implemented more correctly, as we no longer stop at the stacking context boundary while intersecting clip rectangles in the containing block chain. Fixes: SerenityOS#22932 SerenityOS#22883 SerenityOS#22679 SerenityOS#22534
kalenikaliaksandr
added a commit
to kalenikaliaksandr/serenity
that referenced
this issue
Jan 28, 2024
With this change, clip rectangles for boxes with hidden overflow or the clip property are no longer calculated during the recording of painting commands. Instead, it has moved to the "pre-paint" phase, along with the assignment of scrolling offsets, and works in the following way: 1. The paintable tree is traversed to collect all paintable boxes that have hidden overflow or use the CSS clip property. For each of these boxes, the "final" clip rectangle is calculated by intersecting clip rectangles in the containing block chain for a box. 2. The paintable tree is traversed another time, and a clip rectangle is assigned for each paintable box contained by a node with hidden overflow or the clip property. This way, clipping becomes much easier during the painting commands recording phase, as it only concerns the use of already assigned clip rectangles. The same approach is applied to handle scrolling offsets. Also, clip rectangle calculation is now implemented more correctly, as we no longer stop at the stacking context boundary while intersecting clip rectangles in the containing block chain. Fixes: SerenityOS#22932 SerenityOS#22883 SerenityOS#22679 SerenityOS#22534
kalenikaliaksandr
added a commit
to kalenikaliaksandr/serenity
that referenced
this issue
Jan 28, 2024
With this change, clip rectangles for boxes with hidden overflow or the clip property are no longer calculated during the recording of painting commands. Instead, it has moved to the "pre-paint" phase, along with the assignment of scrolling offsets, and works in the following way: 1. The paintable tree is traversed to collect all paintable boxes that have hidden overflow or use the CSS clip property. For each of these boxes, the "final" clip rectangle is calculated by intersecting clip rectangles in the containing block chain for a box. 2. The paintable tree is traversed another time, and a clip rectangle is assigned for each paintable box contained by a node with hidden overflow or the clip property. This way, clipping becomes much easier during the painting commands recording phase, as it only concerns the use of already assigned clip rectangles. The same approach is applied to handle scrolling offsets. Also, clip rectangle calculation is now implemented more correctly, as we no longer stop at the stacking context boundary while intersecting clip rectangles in the containing block chain. Fixes: SerenityOS#22932 SerenityOS#22883 SerenityOS#22679 SerenityOS#22534
kalenikaliaksandr
added a commit
to kalenikaliaksandr/serenity
that referenced
this issue
Jan 28, 2024
With this change, clip rectangles for boxes with hidden overflow or the clip property are no longer calculated during the recording of painting commands. Instead, it has moved to the "pre-paint" phase, along with the assignment of scrolling offsets, and works in the following way: 1. The paintable tree is traversed to collect all paintable boxes that have hidden overflow or use the CSS clip property. For each of these boxes, the "final" clip rectangle is calculated by intersecting clip rectangles in the containing block chain for a box. 2. The paintable tree is traversed another time, and a clip rectangle is assigned for each paintable box contained by a node with hidden overflow or the clip property. This way, clipping becomes much easier during the painting commands recording phase, as it only concerns the use of already assigned clip rectangles. The same approach is applied to handle scrolling offsets. Also, clip rectangle calculation is now implemented more correctly, as we no longer stop at the stacking context boundary while intersecting clip rectangles in the containing block chain. Fixes: SerenityOS#22932 SerenityOS#22883 SerenityOS#22679 SerenityOS#22534
awesomekling
pushed a commit
that referenced
this issue
Jan 28, 2024
With this change, clip rectangles for boxes with hidden overflow or the clip property are no longer calculated during the recording of painting commands. Instead, it has moved to the "pre-paint" phase, along with the assignment of scrolling offsets, and works in the following way: 1. The paintable tree is traversed to collect all paintable boxes that have hidden overflow or use the CSS clip property. For each of these boxes, the "final" clip rectangle is calculated by intersecting clip rectangles in the containing block chain for a box. 2. The paintable tree is traversed another time, and a clip rectangle is assigned for each paintable box contained by a node with hidden overflow or the clip property. This way, clipping becomes much easier during the painting commands recording phase, as it only concerns the use of already assigned clip rectangles. The same approach is applied to handle scrolling offsets. Also, clip rectangle calculation is now implemented more correctly, as we no longer stop at the stacking context boundary while intersecting clip rectangles in the containing block chain. Fixes: #22932 #22883 #22679 #22534
|
Fixed by #22970. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Scrolling the table visually moves the tab bar:
Peek.2024-01-01.11-12.dom.inspector.scrolling.webm
I didn't capture it here, but you can interact with those tabs with the mouse at the location they should be in, not the position they appear, so they're not actually positioned wrong, just painted wrong.
I'm guessing this is a general issue with LibWeb and not specific to the inspector, but at least it's an easy repro.
The text was updated successfully, but these errors were encountered: