Bug 141120 – Negative text-indent with Unicode characters result in positive width

• Component: Layout and Rendering
• Status: RESOLVED DUPLICATE

[Simon Fraser (smfr)]

Reported against chrome here:
https://code.google.com/p/chromium/issues/detail?id=385904

Testcase
http://jsfiddle.net/boggydigital/WJxx8/

[Myles C. Maxfield]

<h1>&#x00c3;&#x00a5;&#x00e2;&#x20ac;&#x00a6;&#x00c2;&#x00ac;&#x00c3;&#x00a5;&#x00c2;&#x008f;&#x00c2;&#x00b8;&#x00c3;&#x00a4;&#x00c2;&#x00bf;&#x00c2;&#x00a1;&#x00c3;&#x00a6;&#x00c2;&#x0081;&#x00c2;&#x00af</h1>test

[Myles C. Maxfield]

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"

[Myles C. Maxfield]

Created attachment 245810 [details]
Reduction

[Myles C. Maxfield]

The "test" is getting moved over by the width of the text before it. However, the text before it is being drawn way offscreen.

[Myles C. Maxfield]

RenderBlockFlow::logicalLeftFloatOffsetForLine() is returning different answers.

[Myles C. Maxfield]

The difference between åaaaaaaaaaaaa and aaaaaaaaaaaaaa is that the first one is breakable. The minimum and maximum preferred logical widths are being updated accordingly.

[Myles C. Maxfield]

Created attachment 245813 [details]
Better reduction

[Myles C. Maxfield]

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?

[Myles C. Maxfield]

Hrm, that doesn't explain why behavior is different if the entire float is non-breakable.

[Myles C. Maxfield]

RenderBlockFlow::computeInlinePreferredLogicalWidths() looks like it's the culprit:

if (!addedTextIndent || hasRemainingNegativeTextIndent) {

[Myles C. Maxfield]

Just below that:
if (!hasBreakableChar)

[Myles C. Maxfield]

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.

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Ahmad Saleem]

Created attachment 468363 [details]
Safari vs Other Browsers

Using 'better reduction', this is still reproducible as can be seen from attached screenshot.

[Ahmad Saleem]

@Alan - it seems to be fixed on WebKit ToT (276246@main) while reproducible on STP90.

Recent Progressions with intrinsic width work?

[alan]

(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.

[alan]

forward duping to bug 271113

*** This bug has been marked as a duplicate of bug 271113 ***