Will update with the test page by cob or tomorrow.

Reporter@ Please provide us sample test file / URL to triage the issue further.

Thanks..

Attached is a test page and the image used. I need to update what I wrote as a plain button does work in Chrome, just fine... what doesn't work are scroll bars and iframe content. The attached test page demonstrates both.
 
If you resure the windows to a 'reasonable' size then the first page will have a button (labeled 'Test') at the top, animage with scroll bars (overflow is set to scroll), and an iFrame with a button in it labeled 'Test iFrame'. These all work on page 1.
 
But on page 2 the 'Test' button works, but the scroll bars on the image and the button in the iFrame do not. On Firefox these work fine.

Deleted: reader5.html 28.0 KB

reader5.html 28.0 KB View Download

Deleted: the-monkeys-paw.jpg 73.1 KB

	the-monkeys-paw.jpg 73.1 KB View Download

This is a blocking support for Chrome Version 54. 

You didn't attach button.html can you provide that too?

Thank you for providing more feedback. Adding requester "jmukthavaram@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

still waiting feedback

Attached button.html

Deleted: button.html 154 bytes

button.html 154 bytes View Download

Here's a more minimal example: https://jsfiddle.net/j5h0tdf6/3/

Can you take a look dtapuska@?

RE comment #4: Are you implying that this worked in Chrome 53? Please confirm.

I'll request a bisect regardless, to get ahead of the problem if it is indeed a regression.

Able to reproduce the issue on Win 10,Mac 10.11.6 and Ubuntu 14.04 using stable 55.0.2883.75 and canary 57.0.2944.0.

Bisect info(Unable to do per-revision-bisect as got script error as "We don't have enough builds to bisect."
========================
Good: 52.0.2715.0
Bad : 52.0.2716.0

You are probably looking for a change made after 389142 (known good), but no later than 389151 (first known bad).
CHANGELOG URL:

https://chromium.googlesource.com/chromium/src/+log/8b6d5f3c021f312bb13f4a4cf2c04bd8f1c5187f..98e094a1f352965d9ea46601f672b3555b56f330

Possible suspect from above CL:
Review URL: https://codereview.chromium.org/1879223002
jbroman@: Could you please take a look into this if its related to your change.
Added releaseblock-stable against M57 as its a recent regression.Please modify if not appropriate.

Far more likely to be either
https://chromium.googlesource.com/chromium/src/+/3cf60f451a7af9826083b316811ce9bbb2479ad5
or
https://chromium.googlesource.com/chromium/src/+/f9ae8afc886232819001f274825a6c55d7fc8482

Re-assigning to mstensho

mstensho, have you had a chance to look into this?

Unfortunately not, but here's a simplified test case.

Deleted: tc.html 1.3 KB

tc.html 1.3 KB View Download

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

commit 90a520011b9e1f70355987371360540c922f4fc9
Author: mstensho <mstensho@opera.com>
Date: Tue Dec 20 09:42:50 2016

Make column snapping optional when translating to flow thread coordinates.

positionForPoint() wants this, but mapAncestorToLocal() requires that no
special behavior be applied.

While this CL doesn't fix  bug 663062 , it is a prerequisite for fixing it
without breaking existing tests (MulticolWithAbsPosNotContained in
MapCoordinatesTest unit test).

BUG= 663062 

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

[modify] https://crrev.com/90a520011b9e1f70355987371360540c922f4fc9/third_party/WebKit/Source/core/layout/LayoutMultiColumnSet.cpp
[modify] https://crrev.com/90a520011b9e1f70355987371360540c922f4fc9/third_party/WebKit/Source/core/layout/MapCoordinatesTest.cpp
[modify] https://crrev.com/90a520011b9e1f70355987371360540c922f4fc9/third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.cpp
[modify] https://crrev.com/90a520011b9e1f70355987371360540c922f4fc9/third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.h

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

commit 797ecc9d67798296b6c8fd2ced17f4716ccbb111
Author: mstensho <mstensho@opera.com>
Date: Tue Dec 20 18:50:14 2016

Need to be inside the flow thread before converting a visual point.

Before we can convert from a visual point to a flow thread point, we need the
input point to be exactly relative to the flow thread, or we might end up
mapping it to the wrong column.

In other words, we need to add the flow thread object's location before
converting into the flow thread coordinate space. While the flow thread indeed
is at 0,0 (or at least close enough to 0,0) relatively to the multicol
container in very many cases, this isn't true when the multicol container is in
rtl writing-mode, or when it's scrollable, or even when the multicol container
has borders and/or padding.

BUG= 663062 

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

[modify] https://crrev.com/797ecc9d67798296b6c8fd2ced17f4716ccbb111/third_party/WebKit/Source/core/layout/LayoutObject.cpp
[modify] https://crrev.com/797ecc9d67798296b6c8fd2ced17f4716ccbb111/third_party/WebKit/Source/core/layout/MapCoordinatesTest.cpp

Thanks guys. We'll look into this fix.

Tested this issue on windows-7, Mac-10.12.2 & Linux Ubuntu 14.04 using chrome Dev version#57.0.2970.0.

Observed that the scroll bars on the image and the button in the iFrame working fine. Hence the fix is working as expected.

Please find the attached screen cast for the same.

Adding TE-Verified labels.

Thanks.

Deleted: 663062.mp4 2.7 MB

	663062.mp4 2.7 MB View Download