Reported against chrome here: https://code.google.com/p/chromium/issues/detail?id=385904 Testcase http://jsfiddle.net/boggydigital/WJxx8/
<h1>公司信息</h1>test
layer at (0,0) size 800x600 RenderView at (0,0) size 800x600 layer at (0,0) size 800x88 RenderBlock {HTML} at (0,0) size 800x88 RenderBody {BODY} at (8,8) size 784x18 RenderBlock (floating) {H1} at (0,21) size 176x38 RenderText {#text} at (-9999,0) size 423x37 text run at (-9999,0) width 423: "\x{C3}\x{A5}\x{E2}\x{20AC}\x{A6}\x{C2}\x{AC}\x{C3}\x{A5}\x{C2}\x{8F}\x{C2}\x{B8}\x{C3}\x{A4}\x{C2}\x{BF}\x{C2}\x{A1}\x{C3}\x{A6}\x{C2}\x{81}\x{C2}\x{AF}" RenderText {#text} at (175,0) size 24x18 text run at (175,0) width 24: "test"
Created attachment 245810 [details] Reduction
The "test" is getting moved over by the width of the text before it. However, the text before it is being drawn way offscreen.
RenderBlockFlow::logicalLeftFloatOffsetForLine() is returning different answers.
The difference between åaaaaaaaaaaaa and aaaaaaaaaaaaaa is that the first one is breakable. The minimum and maximum preferred logical widths are being updated accordingly.
Created attachment 245813 [details] Better reduction
The span's apparent width (meaning: not counting the text-indent) is coming from the minimum preferred width of the text inside the span. That minimum preferred width comes from the width of the longest word, which in this case, is fairly long. In particular, it is longer than the length of the entire text plus the (negative of the) text-indent. I believe this is working as intended. Hyatt: What do you think?
Hrm, that doesn't explain why behavior is different if the entire float is non-breakable.
RenderBlockFlow::computeInlinePreferredLogicalWidths() looks like it's the culprit: if (!addedTextIndent || hasRemainingNegativeTextIndent) {
Just below that: if (!hasBreakableChar)
Created attachment 245827 [details] Prospective patch I haven't read as much as I should of RenderText::trimmedPrefWidths() to really understand this patch, but I figured I would post it so others could take a look.
Comment on attachment 245827 [details] Prospective patch Attachment 245827 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/5568271243804672 New failing tests: fast/text/floating-negative-text-indent-breakable.html
Created attachment 245829 [details] Archive of layout-test-results from ews105 for mac-mavericks-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews105 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Comment on attachment 245827 [details] Prospective patch Attachment 245827 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/6742300285730816 New failing tests: fast/text/floating-negative-text-indent-breakable.html
Created attachment 245830 [details] Archive of layout-test-results from ews101 for mac-mavericks The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-mavericks Platform: Mac OS X 10.9.5
Created attachment 468363 [details] Safari vs Other Browsers Using 'better reduction', this is still reproducible as can be seen from attached screenshot.
@Alan - it seems to be fixed on WebKit ToT (276246@main) while reproducible on STP90. Recent Progressions with intrinsic width work?
(In reply to Ahmad Saleem from comment #18) > @Alan - it seems to be fixed on WebKit ToT (276246@main) while reproducible > on STP90. > > Recent Progressions with intrinsic width work? Good catch! This is exactly what 276246@main would address.
forward duping to bug 271113 *** This bug has been marked as a duplicate of bug 271113 ***