WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
183029
WebKit's intrinsic inline-size calculations don't account for whitespace before empty child with nonzero margins (which causes unnecessary wrapping in intrinsically-sized element)
https://bugs.webkit.org/show_bug.cgi?id=183029
Summary
WebKit's intrinsic inline-size calculations don't account for whitespace befo...
Daniel Holbert
Reported
2018-02-21 23:28:02 PST
STR: Load
https://jsfiddle.net/sjap2xxw/
EXPECTED RESULTS: No space between "aaa" and its bottom border. ACTUAL RESULTS: There's a blank line between "aaa" and its bottom border. Note: Compare to the second "bbb" example in the testcase (which does not wrap) -- that example only differs from the first example in that we've added some text inside the span. So, this seems to be an issue where Safari is incorrectly disregarding the (nonzero) width of empty children's margin-boxes when it computes the intrinsic inline-size of a container. Firefox 60 and Edge 16 produce "EXPECTED RESULTS" on that testcase, BTW. Chrome 66 and Safari 11 produce "ACTUAL RESULTS". Chrome version of this bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=814610
Attachments
[fast-cq]Patch
(3.15 KB, patch)
2024-03-30 16:04 PDT
,
alan
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Daniel Holbert
Comment 1
2018-02-21 23:33:29 PST
Actually, sorry -- Safari and Chrome *do* account for the margins! The thing they're not accounting for is the *whitespace character* just before the empty element. Here's a testcase that demonstrates that (comparing an inline-block *with* whitespace before an empty element with a margin, vs. an inline-block *without* that whitespace character):
https://jsfiddle.net/u1Lbz9oz/
Daniel Holbert
Comment 2
2018-02-21 23:40:33 PST
Oops, sorry -- looks like the testcases that I linked in
comment 0
and 1 actually work correctly in Safari! :D I *started* with a testcase that was broken in both Chrome & Safari, and then I reduced it with Chrome (I'm on Linux) and I assumed it was still the same in Safari.... that'll teach me to make assumptions. Anyway -- here's an earlier version of my testcase that *IS* broken in Safari:
https://jsfiddle.net/xwxsfLpv/
Firefox and Edge render that correctly (with the black line being 1 line tall). Safari and Chrome render it 2 lines tall, for no good reason.
Ahmad Saleem
Comment 3
2022-09-23 07:19:33 PDT
I am able to reproduce this bug in Safari Technology Preview 154 using the test case from "URL" field and it renders the information in two lines while other browsers (Chrome Canary 108 and Firefox Nightly 107) match each other and render it in just one line. Thanks!
Radar WebKit Bug Importer
Comment 4
2024-02-08 15:19:29 PST
<
rdar://problem/122586712
>
alan
Comment 5
2024-03-30 16:04:00 PDT
Created
attachment 470682
[details]
[fast-cq]Patch
EWS
Comment 6
2024-04-01 05:53:21 PDT
Committed
276875@main
(82de10d6c30c): <
https://commits.webkit.org/276875@main
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 470682
[details]
.
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