Bug 59483 - Wrong width after parent’s padding changes
Summary: Wrong width after parent’s padding changes
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-26 12:20 PDT by Sidney San Martín
Modified: 2023-05-05 19:16 PDT (History)
7 users (show)

See Also:


Attachments
Test case (1.41 KB, text/html)
2011-04-26 12:20 PDT, Sidney San Martín
no flags Details
Another test(in the webkit layout test format) (659 bytes, text/html)
2011-05-13 04:38 PDT, Mihnea Ovidenie
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sidney San Martín 2011-04-26 12:20:38 PDT
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.
Comment 1 Mihnea Ovidenie 2011-05-12 12:51:00 PDT
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
Comment 2 Mihnea Ovidenie 2011-05-13 04:38:59 PDT
Created attachment 93432 [details]
Another test(in the webkit layout test format)

A possible layout test for the problem.
Comment 3 Sidney San Martín 2011-05-29 08:49:09 PDT
I’m currently using this workaround from JavaScript, immediately after the parent’s padding changes:

parent.style.display = 'none'; parent.clientLeft; parent.style.display = '';
Comment 4 Ahmad Saleem 2023-05-05 14:14:41 PDT
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?
Comment 5 zalan 2023-05-05 19:16:54 PDT
(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.