New issue
Advanced search Search tips

Issue 652694 link

Starred by 25 users

Issue metadata

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

Blocked on:
issue 625300



Sign in to add a comment

When the introduction of a vertical scrollbar narrows the view port so that it then requires a horizontal scrollbar, the horizontal scrollbar is not shown and content is unreachable

Reported by joolscha...@gmail.com, Oct 4 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0

Example URL:
https://jsfiddle.net/JoolsCaesar/mr5k477t/

Steps to reproduce the problem:
1. Navigate to the https://jsfiddle.net/JoolsCaesar/mr5k477t/
2. Click the "Big" button
3. 

What is the expected behavior?
You should get horizontal and vertical scrollbars

What went wrong?
You only get a vertical scrollbar and the content hidden by the vertical scrollbar is unreachable

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes v52 (I think)

Does this work in other browsers? Yes 

Chrome version: 53.0.2785.143 m  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 21.0 r0

You can actually get it to display both scrollbars if you click "Goldilocks", "Small", "Big"

jsfiddle explanations:
There is a content div within a scrollable div (viewer). The content is set to be the same width as the viewer. The buttons set the height of the content: "Tiny" is 20px < viewer height, "Small" is 10px < viewer height, "Goldilocks" is the exact height of the viewer and "Big" is 10px to big.
 
*too big

This bug is a spin-off from my original bug about Chrome firing false positives for scrollbar detection (https://bugs.chromium.org/p/chromium/issues/detail?id=633602). This bug describes how it has recently start firing false negatives as well.
Cc: skobes@chromium.org szager@chromium.org
Components: -Blink Blink>Layout>Scrollbars
Cc: jmukthavaram@chromium.org
Labels: -Type-Bug M-53 OS-Linux OS-Mac Type-Bug-Regression
Owner: szager@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue in windows Chrome stable (53.0.2785.143), mac,Linux and  canary(55.0.2880.0).

Manual Bisect:

Good build:53.0.2753.0
Bad build:53.0.2756.0

Bisect tool info:

CL : 
https://chromium.googlesource.com/chromium/src/+log/1a3db4d18d2d8c243da9a7e4b8c30c709dbbf352..65c873e2440233e3b12242930190869a5fd90919

Possible suspect:

https://chromium.googlesource.com/chromium/src/+/c9b3e99e2a71f7bcc4d9652916347782ff616e0d

szager@ Please reassign if this is not related to your change.
Blockedon: 625300
Cc: ikilpatrick@chromium.org
This is a known issue without a simple fix.  The LayoutNG project should address it.
Do you know which milestone (A-D) of the LayoutNG project will address this? I'm just wondering whether a fix is a few months away or two years away.
We should never have unreachable content.  The "hard" problem is the treatment of contradictory or self-perpetuating scrollbar existence states, for example scrollbars persisting after Big -> Goldilocks.  But Goldilocks -> Big is a simpler case of one scrollbar necessitating the other.  If r397112 broke that I think we should fix it without blocking on LayoutNG.
Labels: Hotlist-Interop
This works in Firefox and Internet Explorer 11. Interoperability issue.

Comment 8 by e...@chromium.org, Jan 27 2017

Cc: bokan@chromium.org jamiewa...@chromium.org chromoting-bugs@chromium.org w...@chromium.org timloh@chromium.org
 Issue 240772  has been merged into this issue.
The bug this span off from (https://bugs.chromium.org/p/chromium/issues/detail?id=633602) has now been resolved, but this one is still present.

Sign in to add a comment