New issue
Advanced search Search tips

Issue 813345 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Span with white-space:nowrap inside a div with overflow:auto sometimes gets wrapped and creates unnecessary scroll bar

Reported by nos...@vyznev.net, Feb 17 2018

Issue description

UserAgent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/64.0.3282.140 Chrome/64.0.3282.140 Safari/537.36

Example URL:
https://jsfiddle.net/d27hgrfj/3/

Steps to reproduce the problem:
Create a web page with the following HTML (or simply see the linked JSFiddle page):

    <div id="outer">
    <span class="block">A</span><span class="block">B</span>
    <span class="nowrap"><span class="block">C</span>
    <span class="block">D</span></span>
    </div>

and with the following CSS:

    #outer {
      width: 150px;
      background: #afa;
      overflow: auto;
    }
    .nowrap {
      background: #faa;
      display: inline;
      white-space: nowrap;
    }
    .block {
      background: #aaf;
      display: inline-block;
      width: 48px;
    }

What is the expected behavior?
Blocks A and B should appear on one line, with blocks C and D wrapping together onto the next line.  No scroll bar should appear.  (See attached file "correct.png" for a screenshot of the expected rendering, as seen on Firefox 58.)

What went wrong?
The supposedly unwrappable span.nowrap gets wrapped between block C and D anyway.  The space between the two blocks gets rendered on the right side of block C, causing an unnecessary horizontal scroll bar to appear on the outer div.  (See attached file "wrong.png" for a screenshot on Chromium 64.)

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 64.0.3282.140  Channel: n/a
OS Version: 
Flash Version: 

I suspect that the appearance of the scroll bar and the wrapping of the supposedly unwrappable span may actually be separate issues, since I have observed similar issues with semi-randomly appearing useless scroll bars on various Chrome versions over several years.  (See e.g. https://meta.stackexchange.com/questions/240352/horizontal-scrollbar-for-comment-container for an early report, which I managed to "fix" by adding a 2px padding to the outer div.)  However, this is the first time that I've managed to isolate a simple test case that appears to reliably reproduce the bug.

Note that either increasing *or* decreasing the width of the inner blocks (or the outer div) by a few pixels will make the bug disappear.  I suspect that the bug is triggered only when the width of the outer div is enough to accommodate blocks A, B and C (and the space between blocks B and C), but not enough to fully accommodate the space after block C. Both of the spaces before and after block C seem to be necessary to trigger the bug.
 
correct.png
1.2 KB View Download
wrong.png
1.2 KB View Download
Labels: Needs-Triage-M64
Cc: susan.boorgula@chromium.org
Labels: Triaged-ET M-66 FoundIn-66 Target-66 OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
Reporter@ thanks for the issue.

Tested this issue Windows 10, Ubuntu 14.04 and Mac OS 10.12.6 on the latest Canary 66.0.3350.0 and Stable 64.0.3282.168 and able to reproduce the issue.

On loading the given Fiddle, can observe that A,B,C is on one line and D on the next line with a scroll bar below it.
Attached is the screen shot for reference.

This is a Non-Regression issue as this behavior is observed from M60 Chrome builds. 
Hence marking this as Untriaged for further updates from Dev.

Thanks..
813345.PNG
81.3 KB View Download

Comment 3 by junov@chromium.org, Feb 19 2018

Components: -Blink Blink>Layout

Comment 4 by e...@chromium.org, Feb 22 2018

Cc: e...@chromium.org
Status: Available (was: Untriaged)

Comment 5 by nos...@vyznev.net, Feb 22 2018

As a minor correction to my earlier comment above, the space between blocks B and C is *not* necessary to trigger this bug, as the following modified fiddle demonstrates: https://jsfiddle.net/d27hgrfj/5/

(The only differences between this and the earlier fiddle linked above are removing the space after block B and increasing the widths of the blocks by one px to compensate.)

Comment 6 by e...@chromium.org, Feb 22 2018

Thanks for the report and minimal test case.

This works as expected with LayoutNG but fails with the regular layout engine.

Sign in to add a comment