WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
314097
CSS: weird interaction between img with max-width and other elements causes parent element width to go berserk
https://bugs.webkit.org/show_bug.cgi?id=314097
Summary
CSS: weird interaction between img with max-width and other elements causes p...
php4fan
Reported
2026-05-05 09:13:10 PDT
Steps to reproduce: 1. visit
https://opentarget.org/test/stupidwebkit/before-newline
Expected behavior: all three divs should look exactly the same Observed behavior: the third div has a greater width than expected. It's actually the width the content would have if there wasn't a newline after the first "Test test" text. Looks fine in other browser engines, e.g. in Chrome. This seems to have to do with the line break introduced by the ::before element inside the .addline span. But a seemingly unrelated img tag with "max-width: 100%" (which has no expected effect whatsoever in this example) is also needed to reproduce, as demonstrated by the fact that the two divs that don't have it don't reproduce the issue.
Attachments
rendering in safari, firefox, chrome
(94.38 KB, image/png)
2026-05-10 23:59 PDT
,
Karl Dubost
no flags
Details
Test reduction
(201 bytes, text/html)
2026-05-18 08:56 PDT
,
alan
no flags
Details
Patch
(5.98 KB, patch)
2026-05-18 12:11 PDT
,
alan
no flags
Details
Formatted Diff
Diff
[fast-cq]Patch
(5.98 KB, patch)
2026-05-19 05:19 PDT
,
alan
no flags
Details
Formatted Diff
Diff
screenshot after 313488@main
(294.31 KB, image/png)
2026-05-19 10:20 PDT
,
alan
no flags
Details
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Karl Dubost
Comment 1
2026-05-10 23:59:27 PDT
Created
attachment 479590
[details]
rendering in safari, firefox, chrome Thanks. We can see the difference in rendering.
Karl Dubost
Comment 2
2026-05-11 00:11:12 PDT
Testcase: <style> body { margin: 0; padding: 0; } .testmenu { position: absolute; top: 30px; left: 5px; margin: 0; padding: 6px 8px; border: 1px solid black; background-color: #aaaaff } .addline::before { content: '\A'; white-space: pre-line; } .testmenu img.testimg { vertical-align: middle; max-width: 100%; } </style> <body> <div class="testmenu" style="top: 70px"> <img class="testimg" src="
https://placehold.co/24x24/EEE/31343C
" width="24" height="24"> Test Test <br> Test Test <!-- NOTE: no span.addline--> </div> <div class="testmenu" style="top: 150px"> <img src="
https://placehold.co/24x24/EEE/31343C
" width="24" height="24"> <!-- NOTE: no .testimg --> <span>Test Test</span> <span class="addline">Test </span> <span>Test</span> </div> <div class="testmenu" style="top: 230px"> <img class="testimg" src="
https://placehold.co/24x24/EEE/31343C
" width="24" height="24"> <span>Test Test</span> <span class="addline">Test </span> <span>Test</span> </div> </body>
Radar WebKit Bug Importer
Comment 3
2026-05-12 09:14:13 PDT
<
rdar://problem/176889859
>
Ahmad Saleem
Comment 4
2026-05-12 14:04:25 PDT
It is broken on Minibrowser WebKit ToT (
313105@main
) as well.
alan
Comment 5
2026-05-18 08:56:38 PDT
Created
attachment 479703
[details]
Test reduction This looks to be about preferred with computation failing pre-line (only applies to legacy codepath).
alan
Comment 6
2026-05-18 12:11:19 PDT
Created
attachment 479705
[details]
Patch
alan
Comment 7
2026-05-19 05:19:25 PDT
Created
attachment 479713
[details]
[fast-cq]Patch
EWS
Comment 8
2026-05-19 09:03:39 PDT
Committed
313488@main
(38b4e10b7ea0): <
https://commits.webkit.org/313488@main
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 479713
[details]
.
php4fan
Comment 9
2026-05-19 09:19:36 PDT
I see that the comments in the commits talk about failing to trim a trailing white space, but this issue was not just about an extra whitespace, the issue was that the final width of the element would include the entire width of the next line after the line break. Is that also fixed? In other words, does this fix my original test case? The simplified test that was added doesn't seem to check for that, although I may be missing something.
alan
Comment 10
2026-05-19 09:51:08 PDT
You are correct, the simplified test case was over-simplified and that lead to this fix (
bug 315032
-essentially WebKit had another, even more basic bug in preferred-width computation). The combined fix of
313480@main
and
313488@main
addresses your original test case at
https://opentarget.org/test/stupidwebkit/before-newline
(let me paste a screenshot of what I am seeing after
313488@main
)
alan
Comment 11
2026-05-19 10:20:43 PDT
Created
attachment 479719
[details]
screenshot after
313488@main
Sammy Gill
Comment 12
2026-05-21 10:35:01 PDT
Submitted web-platform-tests pull request:
https://github.com/web-platform-tests/wpt/pull/60074
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug