Using the per-revision bisect providing the bisect results,
Good Build: 57.0.2950.0 (revision : 438011)
Bad Build: 57.0.2951.0 (revision : 438385)

You are probably looking for a change made after 438226 (known good), but no later than 438227 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.
 
https://chromium.googlesource.com/chromium/src/+log/1029d11c4d75fd95fa87181056c672f6dafe112d..1667f2eb188cac8da8dcb2fc84a8357fd94b5f61

Review-Url: https://codereview.chromium.org/2468863002

From the CL above, assigning the issue to the concern owner 

@skyostil - 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.

Thanks!

Adding RB Label as this is a recent Regression. Please remove if not required.
Thank You.

Friendly ping to get an update on this issue.

Looks like by switching to ElementVisibilityObserver we've accidentally started throttling display:none frames. I don't think this is safe to do, so I'll figure out a way to work around it. (I tried a hacky way and it makes ESPN work again.)

Just to update regarding the added 'Needs-triage-Mobile' label on the reported version: 57.0.2980.0.

Issue is reproducible on Samsung Galaxy S5 Handset, Android Version: 5.0.0; SM-G900H Build/LRX21T and Galaxy Tab S2, Android Version: 6.0.1; SM-T815Y Build/MMB29K. Layout from Desktop is different but clicking on 'Login' button delay is observed.

 

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

commit 02d1c14d47b948cf6b4eb49c3b4cef697525f03e
Author: skyostil <skyostil@chromium.org>
Date: Thu Jan 26 20:08:04 2017

FrameView: Don't throttle display:none frames

While migrating to use IntersectionObserver to control frame throttling
we accidentally also started throttling display:none frames (which IObs.
considers invisible). This is not safe because many sites use such
frames for driving UI logic.

This patch disallows throttling for display:none frames. The revised
logic also matches the frame throttling implementation in Safari.

BUG= 680925 
TEST=Open the login popup twice on http://www.espn.in/ and observe no delay.

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

[modify] https://crrev.com/02d1c14d47b948cf6b4eb49c3b4cef697525f03e/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/02d1c14d47b948cf6b4eb49c3b4cef697525f03e/third_party/WebKit/Source/web/tests/FrameThrottlingTest.cpp

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

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

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

commit 613b3cabab9f93e9c01962c327239b2f6c81d9c5
Author: Sami Kyostila <skyostil@chromium.org>
Date: Fri Jan 27 10:42:36 2017

FrameView: Don't throttle display:none frames

While migrating to use IntersectionObserver to control frame throttling
we accidentally also started throttling display:none frames (which IObs.
considers invisible). This is not safe because many sites use such
frames for driving UI logic.

This patch disallows throttling for display:none frames. The revised
logic also matches the frame throttling implementation in Safari.

BUG= 680925 
TEST=Open the login popup twice on http://www.espn.in/ and observe no delay.

Review-Url: https://codereview.chromium.org/2658063002
Cr-Commit-Position: refs/heads/master@{#446419}
(cherry picked from commit 02d1c14d47b948cf6b4eb49c3b4cef697525f03e)

Review-Url: https://codereview.chromium.org/2660633002 .
Cr-Commit-Position: refs/branch-heads/2987@{#141}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/613b3cabab9f93e9c01962c327239b2f6c81d9c5/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/613b3cabab9f93e9c01962c327239b2f6c81d9c5/third_party/WebKit/Source/web/tests/FrameThrottlingTest.cpp

Verified this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12 using chrome latest Dev M57-57.0.2987.19 by following steps mentioned in the comment #0 and 
observed no delay while opening Login in overlay.
Hence adding TE-Verified label.

Thanks!

Deleted: Issue 680925.mp4 1.6 MB

	Issue 680925.mp4 1.6 MB View Download

Android: 
Issue verified on 57.0.2987.19, No delay observed while opening on Login page.

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

commit 6d58fe57ab739bbc26291e04bce804721ba5b93d
Author: skyostil <skyostil@chromium.org>
Date: Thu Feb 23 10:53:57 2017

FrameView: Remove redundant tree walk when unthrottling display:none frames

When unthrottling display:none frames, there's no need to synchronously
unthrottle child frames because 1) we're about to walk the subtree
anyway and 2) to match Safari's behavior we actually want to keep
children of display:none frames throttled.

No functional changes, but added a new test to check how children of display:none
frames behave.

BUG= 680925 
TEST=https://jsfiddle.net/ohpkjn9p/2

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

[modify] https://crrev.com/6d58fe57ab739bbc26291e04bce804721ba5b93d/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/6d58fe57ab739bbc26291e04bce804721ba5b93d/third_party/WebKit/Source/core/frame/FrameView.h
[modify] https://crrev.com/6d58fe57ab739bbc26291e04bce804721ba5b93d/third_party/WebKit/Source/web/tests/FrameThrottlingTest.cpp