josh.wood@ if possible can you please provide a testpage or reduced testcase for faster triage of the bug.

Is your iframe cross-origin?  If so, this might be related to site isolation.  Can you try temporarily setting chrome://flags/#site-isolation-trial-opt-out to "Opt out" and report if that fixes your problem?

It'd be great if you could share a sample repro URL or code snippet.  I've tried a quick test with a pointer-events: none div on top of an iframe, but couldn't repro (even with site isolation turned on).

Thanks for the report!  Pre-emptively adding a Site Isolation component, since it sounds plausible.  Does it only affect cross-site iframes?

Agreed that a repro URL or code snippet would help a lot with tracking down the issue.

Ohh, yes chrome://flags/#site-isolation-trial-opt-out fixes the issue on my end.

Yes the iframe is cross origin.

I do not have time to provide an isolated codepen but if you pass through https://hardrocksocialcasino.com as a guest acocunt and go to https://hardrocksocialcasino.com/slots/398

Everything in between the header and footer is an iframe that exhibits the unexpected behaviour.

We just deployed a fix to mitigate the damage from our customer base so the issue should no longer be live. 

But if you, for example, create a full width div with 100% width/height, a background of red and opacity 0.1 with pointer-events: none, after the body you will notice that you are unable to interact with the iframe.

Is this a new security policy being enacted by Chrome or is this behaviour undesired?

Thanks.

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

Comment 5: Thanks for the extra info.  Unfortunately, I can't access that URL as a guest account ("We do not currently allow signups from your state").

I also wasn't able to repro based on your description (with Site Isolation enabled on Chrome 67.0.3396.87 on Windows), using the steps below:
1) Visit http://csreis.github.io/tests/cross-site-iframe.html
2) Open Chrome Dev Tools.
3) In the Console, enter:
var d = document.createElement("div");
d.style = "width: 100%; height: 100%; top:0; left: 0; position: fixed; background-color: red; opacity: 0.1; pointer-events: none";
document.body.appendChild(d);
4) Click the "Go cross-site (complex page)" button and interact with the iframe.

Everything seems to work fine underneath the div.

Did you mean something by "after the body"?  Is there something in my repro steps that doesn't match the case you're describing?  Thanks in advance.

(Site Isolation itself is a new security policy in Chrome, but it shouldn't be preventing input events in cases like this, so we want to diagnose and fix this quickly.)

Ah, you're actually still in time, our deploy hasn't hit live yet.

You should be able to observe the click behaviour on Chrome 67.0.3396.87 with the chrome://flags/#site-isolation-trial-opt-out flag set to default.

You will need to be logged in, so you will need to create an account with a valid email address (no confirmation needed). Otherwise you will be redirected back to the landing page.

The actual game in-between the header and footer (cross-origin iframe) should be blocked by the animations in the footer (part of the main page).

According to the pointer-events spec, clicking the glowy animation above the big button in the center-bottom of the page should click through the glowy rays and through to the iframe. Which it does not.

Thanks, but no luck with creating an account-- I get the same "We do not currently allow signups from your state."  Is there another URL that shows the problem without the same restriction, or a way to modify my repro steps in comment 7 to show it?

Ah, sorry try one of these
http://seminolesocialcasino.com
https://playmountairy.com
https://online.foxwoods.com
https://www.playticasino.com

Same error for me as in #10.  josh.wood@: can you paste in the full styles applied to the <div> that's overlaying the iframe from devtools, so we can see how it's different from Charlie's repro in #7?

They all have varying degrees of obstructing UI, some have quest bars or logos popping out.

The best bet would be to create the slightly transparent div overlaid atop the iframe.

Thanks.  pbommana@ was able to get the game page to load as guest without hitting the state restriction, but he said the game was playable and didn't see the bug.  Perhaps the workaround you mentioned in comments 5 and 8 has gone live?  Can you say more about what the workaround was, so we can try undoing it locally?

(For reference, none of the sites listed in comment 11 work for me-- they all seem to have the same state restriction.)

Yes the workaround just went live.

The workaround was to move any UI elements that were on top of the iframe to move them off. 

There are parts of the iframe that are playable but any UI element from the main document that encroaches on the iframe will bust the click event within what appears to be a horizontal bar.

This is with completely default settings in Chrome 67.0.3396.87.

Ok, with pbommana@'s help, I can see a bit of what's going on, though I haven't been able to repro locally.  I've attached a saved copy of the page and a screenshot.

Based on the description in comment 9, I think "bonusGlowContainer" is the div that's sometimes obstructing input events.  I see the pointer-events: none style on it.  However, I'm not having trouble clicking through it when I load the attached HTML file and navigate the "gameCanvas" frame somewhere else (e.g., https://build.chromium.org).

Ken or Fady, can you try playing with that attached file to see if you can find a case where click events aren't going through it?  In the meantime, I'm trying to get access to a setup where I can repro the bug directly.

It would still be great to get to where my repro steps from comment 7 show the bug, if we can spot the relevant difference.  (Just to check, I tried enabling and disabling chrome://flags/#enable-viz-hit-test-draw-quad as in  issue 851802 , and that didn't seem to affect my steps from comment 7. 
 Might still matter for the real site, though.)

Deleted: Hard Rock Social Casino.html 735 KB

Hard Rock Social Casino.html 735 KB View Download

Deleted: 852095-screenshot.png 3.4 MB

	852095-screenshot.png 3.4 MB View Download

Yep, through my investigation, all children in the bonusGlowContainer obstructed the click through to, for example the "Max Bet" button.

Even adding a JS listener listener to the document and logging event.target reported that I was clicking the iframe. Which is strange.. because an actual iframe click should report nothing, which it did when I clicked on an unobstructed area of the iframe.

Additionally, perhaps you should try host-swapping during your test, maybe there's a cross origin thingy that prevents localhost or the file system from triggering the security violation in chrome.

Cheers, thank you so much for the seriousness you are placing on this issue.

Using the saved HTML file from comment 17, I was able to get the bug to repro on ChromeOS 66.0.3359.203 with Site Isolation enabled (while the subframe was on https://build.chromium.org).  The top and bottom regions of the out-of-process iframe (OOPIF) received no input events, apparently due to layers that were present based on the "largeBacker" div at the top and the "questTrackerContainer" div at the bottom.

I've cut that down to a smaller repro case, attached here.  (I didn't try to bisect or minimize the CSS, which is the majority of the file, but I did cut down to just the HTML elements that set up the problem.

Note that my suspicion in comment 17 was correct-- this bug only seems to repro when you set chrome://flags/#enable-viz-hit-test-draw-quad to Disabled.  I confirmed this on Mac 69.0.3455.0 using the attached test file.

That means this is almost certainly the same underlying problem as  issue 851802 , where a layer from a map is interfering with clicks on a graph in http://bluewatergis.maps.arcgis.com/apps/MapJournal/index.html?appid=5f1e62621fbb4241b1b58424f7040399.

josh.wood@: Can you test out the site with chrome://flags/#enable-viz-hit-test-draw-quad set to Disabled and chrome://flags/#enable-site-per-process set to Enabled?  If the bug goes away, that confirms my theory.

Ken et al: Can we use this extra data point to figure out what fix is needed for the extra layer being created here?  And when is the VizHitTestDrawQuad field trial aiming to launch?  (My understanding is that it's on for 50% of some channels, which might lead to some inconsistent repros if we don't account for it.)

Deleted: Hard Rock Social Casino-edited.html 715 KB

Hard Rock Social Casino-edited.html 715 KB View Download

Quick edit to comment 19: "Can you test out the site with chrome://flags/#enable-viz-hit-test-draw-quad set to *Enabled*" (not Disabled).  Enabling it should hopefully make the bug go away, while disabling it should make it reliably happen on Canary, Dev, Beta, or Stable.  (Thanks for catching the typo, alexmos@!)

Ken/Fady/et al: Is there something we can do for this case, or find a better workaround for the sites to deploy in the meantime?  Given that it affects both this and  issue 851802 , I'm wondering if we can find a small fix that can be merged to M68 and potentially even M67 (if there ends up being a respin).  Tentatively marking Target-67 but we can revise that based on what you find.

Changing the z-index of the headerContainer and footerContainer to -1 makes the input events target correctly, but that might not be visually what you want. This resembles the layer squashing problem that we had resolved in Chrome 64. I need to figure out why we aren't switching to asynchronous hit testing in this case and instead relying on the wrong answer given by synchronous hit testing.

Also adding "Target-68" as this will need a merge to M68.

Tagging as "RBS" for M68 for tracking purpose. Pls feel free to remove if needed. Thanks.

I've confirmed that this is the same cause as  bug 851802 .

Thanks Ken!

Just to followup here as well, a potential fix landed in r567500.  You can star  issue 851802  to follow along if that gets verified and merged, but I'll try to post here when it's in a Chrome Canary version if you want to try it out.

Good news-- the repro case in comment 19 is working again in today's Windows Canary 69.0.3461.2.  We'll plan to get that merged to at least Chrome 68.

josh.wood@: Can you verify that the fix is working on your end?  

My apologies, I have been too busy to keep up with this thread.

Yes, my previous issues have been fixed in Windows Canary 69.0.3461.2.

Thank you so much!

Out of curiosity, would you be able to tell me if my current hack is okay? We have a supportsIFramePointerEvents check that detects whether or not the userAgent contains Chrome/67.0.*

I'm not sure how Chrome's semver works, but should my regex check against 67.* if this fix will make it to 68?

And do you suspect there will be a 67.1 release, or 67.2, 67.3, etc?

#30 -
There has only been once in the entire history of Chrome where the minor version changed (4.0.xxxx.yy to 4.1.xxxx.yy, back when releases were quarterly and not every six weeks), so it will most likely not happen for Chrome 67.

Thanks again everybody! You guys are the best!

Comment 29: Can you say more about what you're doing in the current workaround?  (I'm still unable to see the page directly due to the state restriction from before.)  You're correct that detecting Chrome 67 will be a reasonable way to determine if the bug is present.  You mentioned in comment 15 that you were moving overlay elements off of the iframe in that case, and I believe that should generally work.

The caveat is that part of this bug was due to a Chrome feature called "layer squashing," where Chrome was combining multiple UI elements into a single rectangular layer which might have been bigger than any one element.  That explains why whole regions became non-interactive even when the region didn't correspond to a particular element.  As long as these squashed layers don't overlap the iframe in Chrome 67 with your workaround, you should be fine.  For reference, you can check what layers Chrome is creating in DevTools, using the following steps:
1) Open DevTools for the page.
2) In the "..." menu, go to "More tools" and choose "Layers".
3) Look for any boxes that overlay part of the iframe.

We are indeed aiming for the fix to make it into Chrome 68, once we ensure there aren't any new issues from it on Monday.

It's too soon to tell whether it will make it into a later version of Chrome 67.  While it's true that we generally don't use the "minor" version number (i.e., the second number is basically always zero), we do often put out updated stable releases (e.g., 67.0.3396.79 -> 67.0.3396.87) for things like urgent security fixes.  This might not qualify for that level of release, but if it turns out we need a new release anyway, we might be able to include this fix in it.

Thanks for your help in spotting and helping us understand the bug!

Yep, moving all elements off the iframe was the workaround. We have quite a few animations and flyouts and stuff that intrude onto regions of cross-origin iframes for certain events.

I have never seen the layers feature, will definitely be making use of that! Thank you!

No worries if it doesn't make it into Chrome 67. 

Thanks again!!

Update: Chrome 67.0.3396.99 is now available on the stable channel with the fix.  You can trigger an update manually by visiting chrome://chrome.  Thanks again for the help investigating this one!