Unable to reproduce the issue on win-7 and win-10 using chrome reported version #70.0.3538.67 and latest canary #72.0.3588.0.
Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Ran code in the attached html file.
2. Simulated a mobile phone under Chrome/Windows (e.g. Galaxy S) using dev tools.
3. Observed that the page scrolled to the maximum left but did not scroll to the maximum right. Also observed blue rectangle on the top right corner of the viewport.

reporter@ - Could you please check the attached screen cast and please let us know if anything missed from our end. Also please check the issue on latest canary #72.0.3588.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 897004.mp4 1.1 MB

	897004.mp4 1.1 MB View Download

Someone is able to scroll to the blue rectangle manually.

But in my opinion the blue rectangle should appear one second after loading the page by programmatically javascript:

setTimeout(function() {	
							window.scrollTo(maxScrollLeft, 0);
				}, 1000);	

Deleted: Oct 23, 2018 10_38 AM.webm 1.5 MB

	Oct 23, 2018 10_38 AM.webm 1.5 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on the reported chrome 70.0.3538.67 and latest canary 72.0.3589.0 using Windows 7 & 10, Mac 10.13.6 and Ubuntu 14.04. 
Below is the Manual bisect information for same(As we are getting errors while running bisect).

Bisect Info:
================
Good build: 61.0.3161.0
Bad build: 61.0.3162.0

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/61.0.3161.0..61.0.3162.0?pretty=fuller&n=10000

Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/575768

David Bokan:Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks..!

Please remember: The problem exist under Android/Chrome as well.

Kind regards!

Android Chrome is 70.0.3538.64

The blamed patch was an intentional change.

Because you have horizontal overflow, due to the div with |width: 1700px|, the page can be zoomed out. Chrome sizes the layout viewport to the minimum possible page scale.

Because you have initial-scale=1 in the viewport meta tag, the page is actually "zoomed-in" from the minimum. This means the visual and layout viewports are different sizes.

window.scrollTo operates on the layout viewport, whose width in this case is the device-width * 4 (because 1/4=0.25 is the minimum scale). So the maximum scroll offset for window.scrollTo is actually 1700 - window.innerWidth which is much less than your client width  (which is basically device-width).

Intuitively, you can see better whats going on by zooming out fully before calling scrollTo. 

You have 2 options on how to make this work:

- Remove initial-scale. This will make the page load fully zoomed out so that the visual and layout viewports match and so the element will be visible when you scrollTo.
- Add minimum-scale=1. Also makes the layout viewport match the visual viewport but this time by shrinking the layout viewport to the same size as the visual at scale == 1. That way innerWidth == documentElement.clientWidth

minimum-scale works fine! Thank you!

But I don't understand, why it works in vertical direction without minimum scale.

Deleted: height_005.html 1.3 KB

height_005.html 1.3 KB View Download

It works in the vertical direction because you no longer have a really wide element that causes the layout viewport to get larger than the visual viewport. 

We use only width to expand the layout viewport because Chrome's "load fully zoomed out" behavior is meant to give an overview of the page and prevent horizontal scrolling. Vertical scrolling is expected and common so the expansion/zoom-out works only in the horizontal axis.

Thank you for the information!!!