[Webkit-unassigned] [Bug 117780] New: Floated elements inside a white-space:nowrap container should still wrap
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Jun 18 20:44:20 PDT 2013
https://bugs.webkit.org/show_bug.cgi?id=117780
Summary: Floated elements inside a white-space:nowrap container
should still wrap
Product: WebKit
Version: 528+ (Nightly build)
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Keywords: BlinkMergeCandidate
Severity: Normal
Priority: P2
Component: Layout and Rendering
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: rniwa at webkit.org
CC: hyatt at apple.com, bdakin at apple.com,
simon.fraser at apple.com, dino at apple.com,
robert at webkit.org
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.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list