1729122 - percent padding-top doesn't consistently re-resolve, when the container's size changes

Status: RESOLVED DUPLICATE of bug 1731653

(Core :: Layout, defect)

Description

[adamshumag]

Attachment: Untitled.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

I've set these styles to the block with text:
padding: 10% 0;
max-width: 1000px;

Actual results:

The block's height changes weird and disproportionately. Text remains in place, only bottom padding changes. Refreshing the page will fix it. It works correctly in Microsoft Edge.

Expected results:

The block will changes proportionately.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Can you attach a complete html example that shows the issue? Thanks!

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

I poked around and was able to reproduce the bug (if I'm understanding the reporter correctly).

Important piece missing from the "Steps to reproduce" in comment 0: you have to reduce the width of your browser window. (That's the "Decreased" portion in the the screenshot.)

STR:

1. Load this testcase.
2. Shrink your browser window horizontally (note, this should reduce the resolved value of padding-top:10%)
3. Reload.

EXPECTED RESULTS:
Consistent rendering between steps 2 and 3 (with the green block having less top-padding than in step 1).

ACTUAL RESULTS:
Different rendering between steps 2 and 3. We don't resize the block or move text (to account for reduced padding) in step 2.

Note that we get a similar issue when you increase the browser window's width instead of decreasing it. We do seem to grow the green area a bit sometimes, but it's a bit jerky and we don't grow it quite enough, and we don't repaint text at the proper lower position.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (automatic, no interaction needed). No red should be visible

Comment 5

[Daniel Holbert [:dholbert]]

Sort-of good news, this isn't a regression (or not a recent one). I can reproduce it in Nightly 2012-01-01. Might already be tracked in another bug, given how straightforward the testcase is and how far it goes back...

Comment 6

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

This bug and bug 1700580 makes me wonder whether our nsChangeHint_ReflowHintsForISizeChange [1] is strong enough to mark descendant dirty, because changing a container's isize can definitely affect its children's size if they contain percentage padding.

[1] https://searchfox.org/mozilla-central/rev/08c493902519265d570250c8e7ce575c8cd6f5b5/layout/base/nsChangeHint.h#373-381

Comment 7

[Daniel Holbert [:dholbert]]

Changing severity to S3 given that it's not a recent regression and not-too-catastrophic.

(In reply to Ting-Yu Lin [:TYLin] (UTC-7) from comment #6)

This bug and bug 1700580 makes me wonder whether our nsChangeHint_ReflowHintsForISizeChange [1] is strong enough to mark descendant dirty, because changing a container's isize can definitely affect its children's size if they contain percentage padding.

Yeah; clearly it's not doing enough to handle this right now.

Comment 8

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

This is fixed by bug 1731653, and the testcase is captured in testing/web-platform/tests/css/css-sizing/dynamic-change-inline-size-003.html.