Bug 59483 – Wrong width after parent’s padding changes

• Component: Layout and Rendering
• Status: RESOLVED CONFIGURATION CHANGED

[Sidney San Martín]

Created attachment 91145 [details]
Test case

When the padding of an element is changed, the size of its child elements are not updated until the content (or some CSS properties) of the child elements change or the window is resized.

[Mihnea Ovidenie]

Hi,

I have taken a look at this issue. 

<div id="parent">
    <div id="child">Lorem ipsum ...</div>
</div>

The problem appears when the element "child" is a block element. When the padding of the "parent" for the block element changes, the "parent" is marked as needing layout. However, the "child" element is not marked as needing layout. When the parent is in the process of laying out its children, the layout stops when it reaches the "child" element.

If the "child" element is an inline element, when the "parent" is laid out, "child" element is layout too, being an inline element in a block element.

I was wondering whether it would be ok to modify styleDidChange so that when padding changes, the block children of the element with modified padding should be marked as needing layout? I have tried a change like this, it did not introduce any regression in the existing layout tests. Are there any tests that verify the performance of layout process?

Regards,
Mihnea

[Mihnea Ovidenie]

Created attachment 93432 [details]
Another test(in the webkit layout test format)

A possible layout test for the problem.

[Sidney San Martín]

I’m currently using this workaround from JavaScript, immediately after the parent’s padding changes:

parent.style.display = 'none'; parent.clientLeft; parent.style.display = '';

[Ahmad Saleem]

Using attached testcase (Another test(in the webkit layout test format)), WebKit ToT matches Chrome Canary 115 (needs Ahem font), while Firefox Nightly 114 bleeds red color from top and bottom slightly (few pixels).

@Alan - do we need to do anything?

[alan]

(In reply to Ahmad Saleem from comment #4)
> Using attached testcase (Another test(in the webkit layout test format)),
> WebKit ToT matches Chrome Canary 115 (needs Ahem font), while Firefox
> Nightly 114 bleeds red color from top and bottom slightly (few pixels).
> 
> @Alan - do we need to do anything?
Certainly not. Thank you for testing it.