Unable to reproduce the issue on Win-10 using chrome reported version #63.0.3239.132 and latest canary #65.0.3322.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Clicked on "Sign in with Google Apps"
2. Clicked on the google "Sign In" button
3. Observed that popup appeared to sign in into google account.

Note: Tested with strict site isolation to enabled.

stascheck.fl@ - Could you please check the issue on latest canary #65.0.3322.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Attaching screencast:

Deleted: 801837.mp4 1.9 MB

	801837.mp4 1.9 MB View Download

It's wrongly categorized, the bug is not in the "Log in into Chrome" but on the example URL I sent: https://secure.helpscout.net/members/login/


I'll attach a screencast as well showing that nothing happens if I click on that button (but it works perfectly fine when SSI is diabled -> SSI issue)

-Florian

Deleted: Help Scout - Login - Google Chrome 16.1.2018 22_56_42.mp4 22.8 MB

Help Scout - Login - Google Chrome 16.1.2018 22_56_42.mp4 22.8 MB Download

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

stascheck.fl@ Thanks for the feedback.

Retried this issue again on Windows 10 and Mac OS 10.12.6 using the latest Canary 65.0.3323.0 and Stable 63.0.3239.132 and unable to reproduce the issue.

On navigating to the URL https://secure.helpscout.net/members/login/ -> Clicking on Sign in with Google Apps button, can observe that a popup is appearing where we can sign in to Google account.
Tried the above steps when the flag Strict site isolation is Enabled.
Attached is the screen cast for reference.

Request you to please retry the issue on new chrome profile without any flags/extensions and update the thread with the observations.

Thanks..

Deleted: 801837.webm 3.7 MB

	801837.webm 3.7 MB View Download

Thanks for the report!  (In the future, please label site isolation issues with Internals>Sandbox>SiteIsolation so they get triaged faster.)

Confirmed that this repro works on Mac/Linux 63.0.3239.132 as well as ChromeOS 63.0.3239.116 and 63.0.3239.140 with --site-per-process.  Does not repro on ToT Linux or Mac Canary 65.0.3324.0, so it's likely already been fixed somewhere along the way.

In the repro case, I noticed that the cursor does not change to a hand when you hover over the button like it's supposed to.  *But*, if you slowly move the cursor slightly below the button, I found that there's a position at which the hand cursor appears, and clicking there successfully opens the OAuth popup to appear.  So this appears to be a coordinate transformation issue with OOPIFs.

Ken, do you know what might have caused/fixed this, and whether we have the fix in M64?

Sounds like a bisect would help confirm the fix.  Note that running with --site-per-process is required to repro.

I can confirm the bug on Windows in Chrome 63.0.3239.132 (Stable), 64.0.3282.85 (Beta), and 65.0.3322.3 (Dev).  Doesn't repro on 65.0.3324.0 (Canary), so the fix must have been quite recent.

Bisect results:

You are probably looking for a change made after 529940 (known good), but no later than 529941 (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/3948511dd9cf0e8c38b702e1e707181479f146c3..2d3141fd67830dd068b0bc14218afae8acc844fc

That's Ken's r529941, which is surprising to me.  That CL adds a timeout so that unresponsive renderers don't block further input events.  Would that indicate that there's an unresponsive renderer on the page?  I don't see one in Chrome's task manager, and I don't see how that the small region below the sign-in button would be functional in M63 and M64.

Ken, do you have a sense for why your CL fixes this bug and if it points to a different underlying problem?

This sign-in is an invisible button positioned over top of an OOPIF that is displaying the Google sign-in graphic. I fixed this yesterday as a side-effect of my timeout CL: https://chromium-review.googlesource.com/c/chromium/src/+/865815. It corrected a small error in how we were previously doing asynchronous hit testing.

In the discussion underneath that change I also noted that we need a test case for exactly this scenario.

Great.  I'll consider this fixed in M65.  Just to confirm-- that change isn't mergeable to M64, right?  I assume it's dependent on the other Viz hit testing work in M65.

And yes, let's add a test for this scenario.  :)

Correct, we wouldn't be able to merge it, because it is part of all the work for asynchronous hit testing.

To the reporter: It isn't clear why that page is using an iframe just for the purpose of displaying a graphic underneath the invisible button. If that could be converted to an <img> tag instead of an iframe, that would work around this issue.