My post in product forum: 
https://support.google.com/chrome/forum/AAAAP1KN0B0SLuQq58zVFU/?hl=en

Note to the one who bisects - it is only happening on Windows 7. Windows 10 does not reproduce the issue.

Broken using Chrome 58 on Windows 7, fine using Chrome 57 on Windows 7.
Other platforms do not seem to be affected.

now I am on windows 10 and demo page does not work, yesterday I have tested it on windows 7 and result was same. did you tested demo url?

problem is chrome changes form 57 to 58 nor os version

I tested it using BrowserStack, not on an actual machine.
On Windows 10 is fine, on Windows 7 it is broken.
I used your test URL, yep.

I just re-tested it and it also fails on Windows 10, correct. I am not sure what went wrong (or right ;)) when I tested it earlier.


So broken on Windows (but not on macOS) using Chrome 58.

Since the scrolling is different on macOS, I guess it has something to do with the scrolling code.

Thank U, at least I need some info to make decision, I told my customers to change their browser to edge or Firefox until Chrome new version or till I find the solution. i don't know what changed in chrome to change my code to work properly altogether it works fine in other browsers and 
chrome older version :(

It depends on the impact of the issue and on the root cause (once it is found).
If it is a small, isolated fix in Chrome, it may be merged to Chrome 58 and be released in the coming weeks. Otherwise, it will probably wait until at least Chrome 59 (which will be released in about a month or less).
If it is not a small, isolated fix, it will probably wait until Chrome 59, or even Chrome 60 (depending on the impact of the fix).

But, first, the testing team needs to bisect Chrome in order to find the change that causes this issue and we will be a lot smarted at that point. Bisecting usually takes less than a day (there is a queue).
If you want to do it by yourself, you can, follow the instructions here -
https://www.chromium.org/developers/bisect-builds-py
https://www.chromium.org/developers/bisecting-bugs

The bisecting script -
https://chromium.googlesource.com/chromium/src/+/master/tools/bisect-builds.py

Able to reproduce on Windows-10 using chrome stable M58-58.0.3029.110.

Bisect Information:
=====================
Good build: 58.0.3020.0 (451874)
Bad Build : 58.0.3022.0 (452713)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/9868886dfba0439ec305b876d4ef513b13765752..74be432e0e54671c12f63a8a6fd30cd49687e8c2

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/2716583002

mstensho @ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

I'm not on Windows, so I'm afraid I need someone else to come up with a simplified test that is also reproducible in Linux.

I found a difference that may be important, but I have not debugged the code further to see its impact.

Go to about:blank (for example) and run this code in the console -
    var definer = '<div dir="rtl" style="font-size: 14px; width: 1px; height: 1px; position: absolute; top: -1000px; overflow: scroll">A</div>',
        type = 'reverse';

    document.body.insertAdjacentHTML('afterBegin', definer);
definer = document.body.firstChild;

    if (definer.scrollLeft > 0) {
      type = 'default';
    }
    else {
      definer.scrollLeft = 1;
      if (definer.scrollLeft === 0) {
        type = 'negative';
      }
    }

    
    type;


On Windows - Chrome 57 shows "default" and Chrome 58 shows "negative".
On macOS both of the versions show "default" (I guess it has something to do with the overlay scroll bars on macOS).
What does it show on Linux (does Linux have some sort of overlay scroll bars feature?)?

This is the comment above the code -
  // Borrowed from https://github.com/othree/jquery.rtl-scroll-type
  // Determine the scroll "type" this browser is using for RTL

Line 11539 of http://ui-grid.info/release/ui-grid.js

I just verified that if I make the function return "default", everything works as before. Is there anything hacky about this detection in your opinion, or is it written reasonably?

Also, definer.scrollWidth returns a negative value -
minus16
(Sorry, if I type -16, Monorail thinks it is a plus-one comment)

Is it valid for scrollWidth to be negative (my hunch says no)?

Also see -
https://github.com/othree/jquery.rtl-scroll-type/issues/4

Thanks for the reduction.

I tested in Linux. It's currently "negative", but it becomes "default" if I revert the suspected CL. And, when it comes to  http://ui-grid.info/docs/#/tutorial/120_RTL , it also works fine again if I revert the CL. So I guess I should have ignored the "only happening on Windows 7" claim, and looked a bit more closely. :)

While it was pretty weird before this CL too, Chrome's current behavior now is even inconsistent (scrollable range in RTL vs LTR).

Attaching a demo.

Without the CL the relevant output is:
ltrRange: 25
rtlRange: 25
rtlInitialScroll: 25
Amount of layout width taken by of vertical scrollbar: 15

With the CL (i.e. current Chrome):
ltrRange: 25
rtlRange: 0
rtlInitialScroll: 0
Amount of layout width taken by of vertical scrollbar: 15

Firefox 55:
ltrRange: 10
rtlRange: 10
rtlInitialScroll: 0
Amount of layout width taken by of vertical scrollbar: 12

(all Linux)

Firefox is the only one making sense, in my opinion. Chrome includes the width of the vertical scrollbar in the scrollable range, which seems weird. But I think I'll aim at just reverting to the old behavior in this particular case (we're probably dealing with old weirdness here, so better keep it unless we have some very good reasons). Reverting the CL itself isn't the ideal solution, though.

Deleted: demo.html 1.8 KB

demo.html 1.8 KB View Download

thank you very very much  phistuck and  msten. I hacked ui-grid.js library to return "default" for chrome instead of "negative", but i am waiting for new chrome versions to remove hack, thanks again :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d457f863f78941ed376b463ee39476b1a1852797

commit d457f863f78941ed376b463ee39476b1a1852797
Author: mstensho <mstensho@opera.com>
Date: Wed May 24 09:45:04 2017

When moving past a left-hand scrollbar, don't jump way outside the content box.

We handle rendering, scrolling and scrollbars quite poorly if a scrollbar is
actually wider than its containing block. See crbug.com/724255 for more info on
this corner-case.

We end up with negative values in parts of the code where they are not
expected. This CL is just a simple regression fix to at least make sure that
scrollWidth doesn't get messed up by left-hand scrollbars.

AngularJS depends on this.

BUG= 720227 

Review-Url: https://codereview.chromium.org/2893833004
Cr-Commit-Position: refs/heads/master@{#474226}

[add] https://crrev.com/d457f863f78941ed376b463ee39476b1a1852797/third_party/WebKit/LayoutTests/fast/scrolling/content-box-smaller-than-scrollbar.html
[add] https://crrev.com/d457f863f78941ed376b463ee39476b1a1852797/third_party/WebKit/LayoutTests/fast/scrolling/jquery-rtl-scroll-type.html
[modify] https://crrev.com/d457f863f78941ed376b463ee39476b1a1852797/third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp
[modify] https://crrev.com/d457f863f78941ed376b463ee39476b1a1852797/third_party/WebKit/Source/core/layout/LayoutBlockFlowLine.cpp
[modify] https://crrev.com/d457f863f78941ed376b463ee39476b1a1852797/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/d457f863f78941ed376b463ee39476b1a1852797/third_party/WebKit/Source/core/layout/LayoutBox.h

thank you for review,
should I wait for v60? I don't see any change in 59 behavior.

Yes, 60 it is.