Bug 314097

Summary: CSS: weird interaction between img with max-width and other elements causes parent element width to go berserk
Product: WebKit Reporter: php4fan
Component: CSSAssignee: alan <zalan>
Status: RESOLVED FIXED    
Severity: Critical CC: ahmad.saleem792, karlcow, koivisto, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
URL: https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=14727
See Also: https://bugs.webkit.org/show_bug.cgi?id=315032
https://github.com/web-platform-tests/wpt/pull/60074
Bug Depends on: 315032    
Bug Blocks:    
Attachments:
Description Flags
rendering in safari, firefox, chrome
none
Test reduction
none
Patch
none
[fast-cq]Patch
none
screenshot after 313488@main none

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
DetailsFormatted DiffDiff
[fast-cq]Patch (5.98 KB, patch)
2026-05-19 05:19 PDT, alan 		no flags
DetailsFormatted DiffDiff
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.