Thanks for the report!  I think this is a site isolation problem.  This repros for me with strict site isolation enabled on Linux ToT, but doesn't repro with --disable-site-isolation-trials.  In the repro, there's a "Subframe: https://tableau.com" process in the task manager.

newell.kate@: can you please check if going to chrome://flags/#site-isolation-trial-opt-out and changing it to "Opt out" solves this issue for you?

It seems that mouse input events aren't going to the OOPIF.  When inspecting the problematic <iframe> and looking at its style, I noticed that it has a pointer-events: none applied to it from some other CSS classes, and unchecking that style makes everything work.

+lfg@ who I think worked on pointer events.  Ken or Lucas, any ideas on what might be going on here?

To follow up on #2, the pointer-events: none seems to come from ".media-media{pointer-events:none}" in http://bellingham.maps.arcgis.com/apps/Cascade/app/viewer-min.css?v=1.7.2.

AFAICT the |pointer-events: none| style comes to the tableau's iframe from http://bellingham.maps.arcgis.com/apps/Cascade/app/viewer-min.css?v=1.7.2

FWIW, I've tried opening the repro page (www.cob.org/housingstats) in Firefox 52.6.0 and I also see |pointer-events: none| applied to the iframe but hovering the mouse and clicking seems to work fine (unlike in Chrome with Site Isolation enabled).

tentatively marking this as stable blocker, please correct me if this shouldn't be.

Re: #7, I'll point out that this does not affect all embedded Tableau graphs, just the ones that use the problematic style on the corresponding iframe element.  I have no idea how common that is, though.

For reference, I tried a random embeddable graph on https://csreis.github.io/tests/cross-site-iframe.html, by opening DevTools and executing navFrame("https://public.tableau.com/views/CTSchoolDistrictsbyIncomeandGradeLevels2009-13/Sheet1?:showVizHome=no&:embed=true"), and mouse events in that embedded graph works fine.  The graph comes from https://www.datavizforall.org/embed/tableau/?q= which also works fine.

We're still trying to understand what allows the <iframe> to actually receive mouse events without site isolation.  It still has "pointer-events: none" applied in that mode, and given this, it seems like the <iframe> just shouldn't be receiving any mouse events?

I tried to see how it behaves across different browsers and one thing I noticed that by default if I load the page, scroll to the Housing Types chart, just hovering over it does not highlight or do any tooltips either. If I click anywhere on the chart, it then starts working. This is consistent between Firefox and Chrome without Site Isolation. If the user clicks outside of the chart area, the hovering with the mouse stops working again.

The click on the chart does seem to modify some of the CSS style on the iframe, so it might be likely that changes in style or focus aren't properly being calculated/propagated.

Chatting with pnoland@ (and based on the other Tableau graphs that work in comment 8), we think this is likely an issue on this particular site and may not be widespread.  Something with the pointer-events: none property might be wrong.

We'll continue investigating to see if there's an obvious change that should happen there, and why Site Isolation is behaving differently than the non Site Isolation mode, but based on those findings we don't currently think this is a stable blocker.

It appears that the page is using this library: https://github.com/Esri/storymap-cascade.  This is where the pointer-events: none seems to come from.

I don't know how widespread the library is, but I do see pointer-events: none on an embedded <iframe> graph on a random other site that appears to use it: http://storymaps.esri.com/stories/2016/the-uprooted/index.html.  However, in that page, the iframe is same-site, so there's no issue with site isolation.

The problem seems to be that Chrome fires the mouseleave event prematurely(i.e. right after clicking), which is causing the storymap library to re-add the "scroll-off" class, which prevents interaction. 

Comment 12: Agreed.  Interestingly, certain mouse events make the graph start working again.  On Mac, right clicking makes the graph work.  On ChromeOS, right clicking doesn't seem to help, but dragging the graph background a bit makes it start working.

Sounds like we need to figure out where the extra mouseleave event is coming from for out-of-process iframes (OOPIFs).

This may also give us enough to recommend a workaround for the Esri library?

FWIW, the "drag the graph a bit" workaround sometimes works on Windows, but many times it does not.  Not sure what the difference is.

I narrowed it down to a minimal repro case:
http://csreis.github.io/tests/cross-site-iframe-input-toggle.html

The relevant part is that the iframe is inside a div with event handlers for mousedown, mouseup, and mouseleave.  Normally those events don't go the div when the user clicks on the iframe, but the div will receive them if the iframe has pointer-events: none.  The iframe starts out with pointer-events: none, the mousedown handler removes it, and the mouseup and mouseleave handlers put it back.

When the user clicks on the iframe, the mousedown event goes to the div, and the handler removes the pointer-events: none class from the iframe.  At that point, the input events start going to the iframe, so the mouseup event from the click is normally not seen by the div (and presumably is seen in the iframe).  Thus the iframe normally remains interactive until mouseleave.

Oddly, when the iframe is cross-site (and thus an OOPIF in Site Isolation), the mouseup event still goes to the div rather than the iframe, even after pointer-events: none is removed.  The mouseup handler on the div puts pointer-events: none back on the iframe, so it becomes non-interactive again.

We should figure out why the div is receiving the mouseup event after pointer-events: none is removed in the case of an OOPIF.

Ken, Lucas, or James, can you take a look?

Yes, changing it to Opt-out allows the graph to funtion

This amounts to a special case of the problem discussed in  issue 647378 .

On MouseDown the browser locks input to the renderer process with content currently under the cursor, because of cases where you are dragging an iframe's scrollbar and the mouse leaves the iframe boundary, where we want the drag to continue uninterrupted. That logic is too coarse though, creating bugs like this, which we hadn't anticipated.

 Bug 647378  is not something we can address immediately. There is planned work on the Blink side to remove the notion of implicit mouse capture there, which would help a lot.

A short term fix that might work would be to continue enabling capture on mousedown, but keep hit testing the original mouse down position on subsequent events. The capture would be immediately released if the original position results in targeting a different frame. There are going to be problems with that approach also but it at least could potentially resolve use cases that we know about until we can fix the problem more generally.

Sounds like Ken is working on the short-term fix in the mouse capture logic.

It looks like most of the examples in https://storymaps.arcgis.com/en/app-list/cascade/ are not affected, likely since they do not contain cross-site iframes.  So far http://www.cob.org/housingstats is the only affected site we've found, though there could be others.

The fix I had suggested in #17 looks too disruptive to the existing code to be a good short term solution, because it ends up potentially requiring two asynchronous hit tests on a single event.

Instead, I'm working on a CL that would remove the implicit mouse capture on MouseDown, and have the renderer notify the browser process that a drag is active. This would partially meet the goal of  issue 647378 .

This is also happening further down in the story map in the "Infill Housing" section.  I have an embedded image slider/carousel that was created through "Wowslider" app that is also not functioning in Chrome 67...so this might not be just specific to Tableau, but any other embedded apps in the story maps.

Here is another story map with embedded apps (Infogram app) that is not functioning as expected: 
http://bluewatergis.maps.arcgis.com/apps/MapJournal/index.html?appid=5f1e62621fbb4241b1b58424f7040399

Thanks for the extra info!

Comment 20: Can you saw more about what problem you're seeing in the Infill Housing section?  I'm able to click on the regions in that map and get a popup with more data.

That said, I would expect the previous issue to affect any cross-site iframe with a pointer-events: none overlay, when using this framework.  (I think removing the mouseup event handler might be a workaround until we get a fix in place in Chrome-- I'm not sure why it's needed given the mouseleave handler, and it's the part that is making the graphs non-interactive after you click on them.)

Comment 21: Interesting!  That might be a different issue, since at first glance I haven't found a pointer-events: none issue yet.  I'm specifically looking at the "Discover Crop Acreage of the WIDs" graph in Chrome 67 vs Firefox.  In Firefox, you don't need to click on it before hovering over the graph to see labels.  In Chrome, nothing happens when you hover, and you can't click on the buttons.  The code here seems different enough that I'm not sure if we'll need a second fix for it.

We should look closer to find why that graph isn't interactive.

Comment 20: it isn't in the map section area that the issue is. The section above the map with the black and white images that are on an image slider (Wowslider) that you can't interact with the side handles to move between images.
see attached image for what section I am talking about

Deleted: Wowslide_infill_monorail.jpg 104 KB

	Wowslide_infill_monorail.jpg 104 KB View Download

Comment 21: yes I am looking at the "Discover Crop Acreage of the WID's" side panel section as well and it is not functioning as it should be in Chrome 67.  I am not the author of this story map, but I was just hunting around to see if it was specific to Tableau and noticed this not functioning, as well as my image slider not functioning in my housing stats story map.

Comment 23: Thanks!  I can repro that, and it does look like the same problem as the original issue, where a layer is preventing interaction, it goes away on mousedown, and it comes back on mouseup.  I think Ken's fix should address that, and it sounds like he's making progress on it.

Comment 24: Thanks for the context.  Can you file a separate bug for that case and let us know the bug number?  We think it's a different issue than the fix being discussed here, and we're seeing inconsistent results across versions and profiles.  I suspect that some other field trial is involved.  Thanks!

Comment 24: Yes, you are right its also funky in IE.  Probably different issue. I can file a bug for that, but also I'm not the author of the story map so can't provide any detail other than "not working". Thanks. Looking forward to a fix on the other issues.

Quick update: I filed  issue 851802  for the Blue Water GIS site, since I think I tracked down which field trial was involved.  As a temporary workaround, you can set chrome://flags/#enable-viz-hit-test-draw-quad to Enabled and I think that one should work.

I have a potential fix uploaded, which has a couple of minor issues to be worked out and then needs code review.

https://chromium-review.googlesource.com/c/chromium/src/+/1099183

Just to post an update before the weekend, the CL in comment 28 is making progress, and we hope to land it soon.  We'll let you know when it's in a Chrome Canary to verify the fix.

(The fix for  issue 851802  also landed and is in the 69.0.3461.2 Canary.)

Any updates? Is there a timeline when we expect a fix?

I'm hoping to land the fix for this today, and will request merge approval to get it into Chrome 68. That version gets promote to Stable channel in approximately a month.

So won't be fixed for over a month! yikes...that is unfortunate.

Is there any possibility of using the workaround from comment 22?  Specifically, the mouseup handler is putting the pointer-events: none layer back at the end of the click, which seems potentially unnecessary.  The mouseleave handler does that already for the case that seems to matter.  Not sure if there's a way to change that as a short term workaround?

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

commit 94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04
Author: Ken Buchanan <kenrb@chromium.org>
Date: Fri Jun 22 19:56:24 2018

Make Blink control browser mouse capture for scrollbar drags

The current behavior to allow mouse input in the browser process to be
locked to a given RenderWidgetHost is to send all mouse input between a
MouseDown and a MouseUp to the same target. This is not in accordance
with spec, and causes some site breakage.

Whether a MouseDown should cause capture depends on the node that the
event hits. Drag-highlighting text or clicking the thumb part of a
scrollbar require capture, for instance, while most elements do not.

This change removes the implicit capture currently done in the browser,
and replaces it in the case of scrollbars with an explicit signal from
Blink to start capturing. Other cases requiring capture still need to
be implemented.

Bug:  647378 ,  849862 
Change-Id: Ifc4b690c36927ed48edd2604d40742e130295dcf
Reviewed-on: https://chromium-review.googlesource.com/1099183
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Ella Ge <eirage@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569740}
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/browser/renderer_host/input/input_router_client.h
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/browser/renderer_host/input/input_router_impl.cc
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/browser/renderer_host/input/input_router_impl.h
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/browser/renderer_host/input/input_router_impl_unittest.cc
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/browser/renderer_host/input/mock_input_router_client.h
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/browser/renderer_host/render_widget_host_input_event_router.cc
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/browser/renderer_host/render_widget_host_input_event_router.h
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/browser/site_per_process_hit_test_browsertest.cc
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/common/input/input_handler.mojom
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/renderer/render_frame_impl.h
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/renderer/render_widget.cc
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/renderer/render_widget.h
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/content/renderer/render_widget_unittest.cc
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/third_party/blink/public/web/web_local_frame_client.h
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/third_party/blink/renderer/core/exported/local_frame_client_impl.cc
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/third_party/blink/renderer/core/exported/local_frame_client_impl.h
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/third_party/blink/renderer/core/frame/local_frame_client.h
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/third_party/blink/renderer/core/input/event_handler.cc
[modify] https://crrev.com/94c0beb64439fec7c5e5b0d9b7d45f2bcab4dc04/third_party/blink/renderer/core/input/event_handler.h

Thanks Ken!  We expect the r569740 fix will be in the next Canary, likely 69.0.3470.0.  Once we verify that it's working and not causing regressions, we can evaluate merging to M68.

For reference, I've applied r569740 to a local M68 branch and I can verify that it fixes the bug (both in the first table and in the infill housing case mentioned in comments 20-23).  The updated CrossProcessMouseCapture test also passes locally (if I enable it, since it was disabled on the M68 branch).

There were several merge conflicts when applying it to the M68 branch, but they're mostly just textual.  I've uploaded the draft merge CL at https://chromium-review.googlesource.com/c/chromium/src/+/1112757.  It's not ready to review or land until we verify the fix in Canary and request merge, but I have it handy for when the time comes (along with notes about where all the conflicts were).

Thanks for all the work on this.  Due to the amount of time until a fix is implemented, I am going to have to adjust my webpage to a less than ideal temporary fix so that users can have some functionality in Chrome (put the Tableau table in an "immersive" section which functions slightly better, though not perfect and add static jpgs of the infill housing).  I look forward to hearing when the fix is implemented and I can restore the original functionality of the housing stats web page.  Thanks

Comment 37: Thanks for the heads up.  The fix is available on today's Chrome Canary (69.0.3472.0), and it seems to be working on the current version of the site, which doesn't seem to have changed yet.  Can you confirm the fix there?

Due to IT restrictions at my organization, I am not allowed to download/install Chrome Canary. I can send an IT request but could take some time. Sorry :(

That's ok-- we were at least able to verify it locally.  We're going to make sure things go smoothly with today's Canary, and then we'll request merge to M68 tomorrow.

This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

The NextAction date has arrived: 2018-06-26

Chatted with creis@, he was able to verify this locally. Approving merge for M68 (branch:3440), but please confirm and validate this fix in today's canary first. 

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

commit 5aa4e3d02d9b674032174732e5998afa924c0523
Author: Charlie Reis <creis@chromium.org>
Date: Tue Jun 26 18:12:19 2018

Merge to M68: Make Blink control browser mouse capture for scrollbar drags

The current behavior to allow mouse input in the browser process to be
locked to a given RenderWidgetHost is to send all mouse input between a
MouseDown and a MouseUp to the same target. This is not in accordance
with spec, and causes some site breakage.

Whether a MouseDown should cause capture depends on the node that the
event hits. Drag-highlighting text or clicking the thumb part of a
scrollbar require capture, for instance, while most elements do not.

This change removes the implicit capture currently done in the browser,
and replaces it in the case of scrollbars with an explicit signal from
Blink to start capturing. Other cases requiring capture still need to
be implemented.

Bug:  647378 ,  849862 
Change-Id: Ifc4b690c36927ed48edd2604d40742e130295dcf
Reviewed-on: https://chromium-review.googlesource.com/1099183
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Ella Ge <eirage@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#569740}
Reviewed-on: https://chromium-review.googlesource.com/1112757
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#535}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/browser/renderer_host/input/input_router_client.h
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/browser/renderer_host/input/input_router_impl.cc
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/browser/renderer_host/input/input_router_impl.h
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/browser/renderer_host/input/input_router_impl_unittest.cc
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/browser/renderer_host/input/mock_input_router_client.h
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/browser/renderer_host/render_widget_host_input_event_router.cc
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/browser/renderer_host/render_widget_host_input_event_router.h
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/browser/site_per_process_hit_test_browsertest.cc
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/common/input/input_handler.mojom
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/renderer/render_frame_impl.h
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/renderer/render_widget.cc
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/renderer/render_widget.h
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/content/renderer/render_widget_unittest.cc
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/third_party/blink/public/web/web_frame_client.h
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/third_party/blink/renderer/core/exported/local_frame_client_impl.cc
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/third_party/blink/renderer/core/exported/local_frame_client_impl.h
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/third_party/blink/renderer/core/frame/local_frame_client.h
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/third_party/blink/renderer/core/input/event_handler.cc
[modify] https://crrev.com/5aa4e3d02d9b674032174732e5998afa924c0523/third_party/blink/renderer/core/input/event_handler.h

The NextAction date has arrived: 2018-07-25

Just to follow up on comment 37, Chrome 68.0.3440.75 is starting to roll out to the stable channel with the fix for this issue.  A small percentage of users will see the update at the moment, and we'll ramp that up to 100% in about a week or so.  (You can update manually by visiting chrome://chrome.)

Hope that helps with restoring the original functionality of the site, and sorry again for the inconvenience!