WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
117780
REGRESSION(
r143479
): Floated elements inside a white-space:nowrap container should still wrap
https://bugs.webkit.org/show_bug.cgi?id=117780
Summary
REGRESSION(r143479): Floated elements inside a white-space:nowrap container s...
Ryosuke Niwa
Reported
2013-06-18 20:42:57 PDT
Consider merging
https://chromium.googlesource.com/chromium/blink/+/83e189ab24ed21ecc254805c14e0947bf6eeccd1
This behavior matches Firefox and fixes the min-content bug exposed by
http://trac.webkit.org/changeset/143479
. All the new layout test baselines match Firefox except for fast/css/word-space-extra.html. We incorrectly compute the minPreferredLogicalWidth when there is word-spacing involved. In this case, our old behavior was also wrong. Now it's just slightly worse. I spent 3 days trying to fix our word-spacing implementation to make sense and gave up eventually. Hopefully, as we go through and clean up the code involved it will be come easier to fix this in the future. modified: Source/core/rendering/RenderBlock.cpp The old code here was wrong. In the presence of floats, the minLogicalWidth of a nowrap container can be smaller than it's maxLogicalWidth. Unfortunately, fixing this exposes some bugs in our minLogicalWidth computation. modified: Source/core/rendering/RenderText.cpp This fixes one of the bugs exposed by removing the code in RenderBlock. m_hasBreakableStart and m_hasBreakableEnd are eventually exposed to RenderBlock::computeInlinePreferredLogicalWidths. They are only used in order to determine if the beginning/end of the RenderText is a possible wrapping location. In a nowrap container, spaces do *not* represent wrapping locations, so these bools should be false in that case. But, to make this more fun, we still need to track whether the RenderText ends in spaces or newlines so that we can correctly set the stripFrontSpaces bool, which controls stripping the leading spaces in the *next* RenderText.
Attachments
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2013-06-19 10:00:12 PDT
So, is there a regression on a live web site exposed by
r143479
? We should prioritize by the symptom then.
Ryosuke Niwa
Comment 2
2013-06-19 10:03:50 PDT
See
https://code.google.com/p/chromium/issues/detail?id=244777
Radar WebKit Bug Importer
Comment 3
2013-06-20 00:20:21 PDT
<
rdar://problem/14213678
>
Ahmad Saleem
Comment 4
2024-03-24 16:05:25 PDT
Took added test from Blink and remove prefixes `min-width: min-content` and then changed it to `JSFiddle`: Test Case -
https://jsfiddle.net/dwhrqkb9/show
^ It seems to run same across WebKit ToT, Chrome Canary 125 and Firefox Nightly 126. @Alan - any input?
Karl Dubost
Comment 5
2024-03-24 18:22:00 PDT
yes it is working the same everywhere.
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