Verified the issue on Latest Canary# 51.0.2704.2 on Windows and could not reproduce the issue.
Able to scroll down the chat history and contacts also.

@dcheng -- Could you please let me know if i have missed anything.
Thank You.

Well it seems I'm the only one that can repro this. I honestly don't know if it happens on stable, but my recollection is the problem was happening there too...

Based on comment#2 and offline Chat with dcheng@ marking the bug as stable blocker.

Thank you for providing more feedback. Adding requester "msrchandra@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to repro this issue on Windows 7 for Google Chrome Dev Version - 51.0.2704.19 

Screen-recording is attached.

Deleted: 601875.mp4 761 KB

601875.mp4 761 KB Download

@dcheng : Could you please re-test the same on Chrome Dev Version - 51.0.2704.19 (or) Chrome Canary Version - 52.0.2711.0 and let us know your observations.

I'm still unable to scroll (I'm currently on Windows 51.0.2704.7 (Official Build) dev-m (64-bit), which seems to be the latest dev build available to me).

Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to repro this issue on Windows 7 for Google Chrome Dev Version - 51.0.2704.19 

Screen-recording is attached.

@MTV: Verified it on all available Windows 10 machines and couldn't repro this issue, could you please re-test on the Windows 10 systems available in MTV and update the thread accordingly.

Thank you.

Deleted: 601875.mp4 4.9 MB

601875.mp4 4.9 MB Download

Correction: Systems tested - Windows 7 & 10 [Pro]

dcheng@ : Unable to reproduce the issue on Win 7 using 52.0.2717.0.Could you please provide the screen cast if its still an issue.

I had an offline chat in past with  dcheng@ and based on our chat he wasn't able to reproduce the issue. We are leaving the bug open just to make sure if we can get any 100% reproduction steps we can update further on this bug. 

I am able to repro, but only on my Win10 machine. I'm not sure how to take a screencast.

Thank you for providing more feedback. Adding requester "durga.behera@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

You can download the screen recorder from "screencast-o-matic.com" and share your screen cast attaching here.

A friendly reminder that M51 Stable is launching soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch by May 17. All changes MUST be merged into the release branch by 5pm on May 20 to make into the desktop Stable final build cut. Thanks!

Unable to reproduce it on Win 10,Win 7 using Beta 51.0.2704.36, Dev 52.0.2729.3 and canary 52.0.2730.0.
Removing the ReleaseBlocker for now, feel free to add it if you still able to reproduce  it with valid steps for the same.

dcheng@ : Could you please update following the above comment # 15 for screen recording.

@dcheng: Could you please update us as per the comment #17

Thank you.

I tried to bisect this locally. 80% of the time, I can't even sign in to Chrome, which means I can't use the Hangouts app. So I'm having trouble bisecting down this failure.

I did notice one thing though: if I increase the zoom 3 times, then the scrollbar starts working. So maybe there's something broken with hit testing here?

Since the Hangouts app uses <webview>, CCing some <webview> people in hopes that this sounds vaguely familiar to someone...

Thank you for providing more feedback. Adding requester "durga.behera@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Friendly ping to get an update on this issue as per C#19.

Untriaging it so that it gets addressed. Could someone please respond as per comment# 19.

This looks like it might be related to https://bugs.chromium.org/p/chromium/issues/detail?id=616506, which I have already started and have an understanding of the failure (and a potential fix).

When I'm back in the office on Monday I'll see if my fix works for this issue as well.

It does seem to be an issue around event coordinates; dcheng@, are you scrolling with touchscreen? touchpad? mousewheel? dragging the scrollbars with the mouse?

 Issue 617021  has been merged into this issue.

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

commit 288a99fe15afb1dfefbe253aaa3a5de3c249d866
Author: wjmaclean <wjmaclean@chromium.org>
Date: Tue Jul 19 23:45:42 2016

Queued wheel events should not use ScopedInputScaleDisabler.

Since WebMouseWheelEvents returned by BrowserPlugin are sent to the
guest's RenderWidgetHostImpl, which queues them and (may) send them
later, they should have the device_scale_factor explicitly removed, as
RenderWidgetHostImpl/InputRouterImpl may re-add it before sending.

BUG= 601875 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

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

[modify] https://crrev.com/288a99fe15afb1dfefbe253aaa3a5de3c249d866/content/browser/frame_host/render_widget_host_view_guest.cc

 Issue 616506  has been merged into this issue.

Before we approve merge to M52, Could you please confirm whether this change is baked/verified in Canary and safe to merge?

Also is this require a merge to M53?

I discussed with gkihumba@ and we're going to merge directly to M52 (no canary, as the CL missed the last one ... but we're confident it's still a safe merge). I'll be doing the merge shortly.

[Automated comment] Less than 2 weeks to go before stable on M52, manual review required.

Your change meets the bar and is auto-approved for M53 (branch: 2785)

[Automated comment] Less than 2 weeks to go before stable on M52, manual review required.

After talking offline with Krishna, we've agreed to merge the cl into m52 now and if there's an issue we'll revert the cl tmrw am

Removing "Merge-Review-52" label as M52 merge is approved based (comment #37).

Please note that for Desktop M52 is already in stable and bar is VERY high, I only agree to take this change in as it blocking Chrome OS RC cut. So please revert the change immediately if there's an issue.

gkihumba@ and wjmaclean@, please make sure that this change gets tested/verified in canary and M52 branch as Chrome Desktop Test team is unable to repro the bug. 

dcheng@, could you please verify the fix on Windows 10 once the change is landed as you're able to repro the bug per comment #13.

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

commit a5b162a5c9cc4ad68a087026a14484a686490123
Author: Grace Kihumba <gkihumba@google.com>
Date: Thu Jul 21 00:01:02 2016

Queued wheel events should not use ScopedInputScaleDisabler.

Since WebMouseWheelEvents returned by BrowserPlugin are sent to the
guest's RenderWidgetHostImpl, which queues them and (may) send them
later, they should have the device_scale_factor explicitly removed, as
RenderWidgetHostImpl/InputRouterImpl may re-add it before sending.

BUG= 601875 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2164673002
Cr-Commit-Position: refs/heads/master@{#406417}
(cherry picked from commit 288a99fe15afb1dfefbe253aaa3a5de3c249d866)

Review URL: https://codereview.chromium.org/2168773002 .

Cr-Commit-Position: refs/branch-heads/2743@{#678}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/a5b162a5c9cc4ad68a087026a14484a686490123/content/browser/frame_host/render_widget_host_view_guest.cc

gkihumba@ and wjmaclean@, please update test result for Canary and M52 build to confirm fix is working as expected and no regression. Thank you.

The scrolling works fine in the hangouts app on 52.0.2743.85 / 8350.60.0 build.

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

commit c3126c7e2d32256f33087c329600bb01b48be7fe
Author: W. James MacLean <wjmaclean@chromium.org>
Date: Fri Jul 22 13:00:40 2016

Queued wheel events should not use ScopedInputScaleDisabler.

Since WebMouseWheelEvents returned by BrowserPlugin are sent to the
guest's RenderWidgetHostImpl, which queues them and (may) send them
later, they should have the device_scale_factor explicitly removed, as
RenderWidgetHostImpl/InputRouterImpl may re-add it before sending.

BUG= 601875 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2164673002
Cr-Commit-Position: refs/heads/master@{#406417}
(cherry picked from commit 288a99fe15afb1dfefbe253aaa3a5de3c249d866)

Review URL: https://codereview.chromium.org/2174633003 .

Cr-Commit-Position: refs/branch-heads/2785@{#294}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/c3126c7e2d32256f33087c329600bb01b48be7fe/content/browser/frame_host/render_widget_host_view_guest.cc

Verified the issue on Windows-7 & Ubuntu 14.04 using chrome latest Dev M53-53.0.2785.30 by following steps mentioned in the original comment. Observed the scroll on the very right for the chat history is working as expected. Hence adding TE-Verified label.

Deleted: HangoutScroll.mp4 1.2 MB

	HangoutScroll.mp4 1.2 MB View Download

Unable to reproduce the issue on win7,10 using chrome version 51.0.2700.0, 52.0.2743.82 and canary 54.0.2815.0

gkihumba@ and wjmaclean@, Friendly ping to get an update on the test result of the fix as per comment #38 and 40 since not reproducible in reported version as well from test team end.

This was not  reproducible on desktop but on CrOS. As per #41 , tagging as verified.

Verified on Cros as per comment 41