@orr.paradise@gmail.com: I am not able to reproduce the issue. 

Try opening https://www.arista.com/assets/data/pdf/user-manual/um-eos/Chapters/VLANs.pdf and check if that works fine. 

For me the touch display and trackpad works as intended in Kevin. 

70.0.3524.2 / 10991.0.0

This pdf doesn't work for me on Pixelbook (none of the pdfs work)

I was using the Samsung Chromebook Plus. (Right now am away from the device, will try again in the weekend)

I don't seem to be able to reproduce this issue either. Reporter please get back to us with more information about your setup and steps to reproduce whenever you got access to the Chromebook.

Henrique, do you know who handles the scrolling for pdf plugin?
It seems that screen zooming works as well as keyboard scrolling. But touch scrolling and touchpad scrolling don't.
I wasn't able to reproduce the issue myself but just wondering how we should proceed here.

Also just to sanity check, this is with the Chrome PDF Viewer, and not some third party PDF viewer extension, right? Can you try temporarily disabling all browser extensions just to make sure they are not interfering?

The issue still occurs on my machine, also when disabling all extensions. I'll also add that I have developer mode on (for crouton). What other logs / information can I provide?

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

Indeed using the Chrome PDF Viewer and not a 3rd party app. An important thing to clarify is that I'm using the Chrome browser in Chrome OS (huge apologies if this means that I've been wasting everyone's time).

orr.paradise@: thanks for the feedback. Could you capture a trace using these instructions: https://www.chromium.org/developers/how-tos/submitting-a-performance-bug. Attach it here - make sure all the boxes under "Record Categories" are enabled (Disabled by default categories can stay off). 

I went to the suggested pdf[1] and tried scrolling with the track pad, then with the touch screen.

[1] https://www.arista.com/assets/data/pdf/user-manual/um-eos/Chapters/VLANs.pdf

Deleted: trace_pdf_scroll.json.gz 2.6 MB

trace_pdf_scroll.json.gz 2.6 MB Download

Strange, for the mouse wheel - we are dispatching blocking GestureScrollUpdates but (at least in the trace) they're not going anywhere, they get ACKd as CONSUMED very quickly I don't see any activity in any other process.

There's a similar situation for the touch events in the trace but we occasionally get back a NOT_CONSUMED touch ACK and there's a bit of regular activity in the PPAPI process at the same time. We don't produce gesture scrolls for the touches though.

Can anyone repro this locally?

Seems to have been fixed in 70.0.3532.8

@jmeurin Just upgraded to 70.0.3532.8, the issue is not fixed. Attached are logs from the reproduction on 70.0.3532.8.

Deleted: trace_70035328.json.gz 3.7 MB

trace_70035328.json.gz 3.7 MB Download

Hi, this is happening to me on two Pixelbooks, version 70.0.3532.8.

I am unable to scroll using the internal trackpad on PDFs using the built-in PDF viewer.

E.g. PDF:
https://downloads.monoprice.com/files/manuals/15365_Manual_170509.pdf

The cloest device I have is a Samsung Chromebook Pro, which I update to M70, but scrolling works fine for me.

bokan: Are you aware of any experiments or users settings that may be trigger this?

mlepage: Glad you have a repro. Can you work with bokan@ and see what's going on?

No, nothing on our end. I'm a bit swamped this week - chaopeng@, sounds like this is reproducing consistently on pixelbooks - could you track one down and take a look.

I found a local dev Pixelbook and was able to repro easily. Chao, I left it on your desk, PTAL.

The one you left on my desk can not reproduce. You feel it can not scroll because this one sets Touchpad scrolling direction to traditional (reverse the scroll direction).

Ah...drats - that's embarrassing.

mlepage@, you mentioned your work one no longer reproduces. Is your home one still reproing? Are they on the same version?

Issue still occurs in 70.0.3538.7.

I'm having the scrolling problem as described here in 70.0.3538.7 running on Eve. Cannot scroll PDF with trackpad OR touching the screen. Space, arrow keys, and arrow key + alt (+ ctrl) scrolling works. I can also drag the location indicator in the scrollbar.

I had this scrolling problem as well.  I ended up deleting my profile on my Pixelbook and re-logging back in and the problem went away.

Try creating a new profile (log in with a new/different email) to see if it resolves itself?

This does seem like it may be caused by an experiment. From one of the traces above, the #enable-viz-hit-test-draw-quad experiment is on as well as #pdf-isolation, both  of which seem like they may be involved but I can't repro even when turning those on.

+sadrul@, any ideas?

bdd@, if you can still repro this, would you capture a trace following the instructions in #12 - ideally without any other tabs open. If you could go to chrome://version and copy+paste everything in "Variations" here.

+riajiang@, +kenrb@

viz-hittest experiment can affect this. Ria: can you try to repro?

I don't know what pdf-isolation is, but it sounds like something that could affect this too.

pdf-isolation is site isolation for the PDF plugin. Have multiple PDF plugins instead of only 1 for all PDFs.

If we have a list of potential culprits, maybe force them on / off and see if any of them trigger this bug?

+riajiang@, +kenrb@ for realz this time

I tried on dev channel 70.0.3532.8 on eve with VizHitTestDrawQuad turned on but wasn't able to repro it (also tried with both VizHitTestDrawQuad and PDF Isolation on but couldn't repro)

For anyone who's seeing this: could you please attach a trace and share your variations as requested in #26.

mlepage@: Does this still occur on any of your pixelbooks?

I am not seeing it on my work Pixelbook. I will check my home Pixelbook tonight (I sent myself a reminder).

bokan@ unfortunately I can't reproduce now. I was in fact able to reproduce this between restarts, in normal and incognito mode and with all extensions disabled but right now, not even restarted, just waking the machine from a long sleep, I cannot reproduce.  Attached chrome://version output from currently running 70.0.3538.7 butthe machine already got the update for 70.0.3538.16 and waiting for restart. If at any point I can reproduce this on .16, I will take a full trace and update this issue.

Deleted: chrome-version.txt 4.2 KB

chrome-version.txt 4.2 KB View Download

Even though my work Pixelbook and home Pixelbook are configured the same (same channel, same crostini, etc.) it seems I don't see it any more on the work Pixelbook (but did!), but I *do* still see it on the home Pixelbook. bokan@ came over and grabbed some traces, hopefully that will lead to a fix soon! Also, if anything changes (e.g. work one starts having the issue again, or issue goes away on home one) I'll post more details here.

Another thing I've noticed in about the same time frame is the LastPass extension (which I use at home but not at work) dialog thing that pops up (when I type a password in a site it doesn't know about) is totally non-interactable (and non-dismissable) now. Could be related.

I got mlepage@ to demo the issue for me. We looked at a corp and non-corp pixelbook - on the same dev channel version (70.0.3538.7). The corp laptop works but the home laptop doesn't (this bug repros).

I've attached a diff of the experiments on each system, taken between the Broken (<) and Working (>).

Also attaching scroll captured from broken device.

The extension issue is likely related and is another indication this is some kind of process input routing issue (extensions are also rendered out of process) 

Deleted: trace_cantscroll.json.gz 4.4 MB

trace_cantscroll.json.gz 4.4 MB Download

Deleted: variations.diff 5.9 KB

variations.diff 5.9 KB Download

Filtered out highly unlikely experiment candidates, here's what's left:

Experiments on broken machine:
< BackgroundPagePriority-BestEffortPriorityEnabled_V2
< DelayUnsafeAds-DelayUnsafeAds
< LowPriorityIframes2-Enabled
< PdfIsolation-Control
< SitePerProcess-Control_25_20180606
< VizHitTestDrawQuad-Experiment
< BlinkSchedulerHighPriorityInput-Enabled2
< BlinkSchedulerHighPriorityInputOnCompositorThread-Enabled
< BlinkSchedulerPrioritizeCompositingAfterInput-ImplicitSignals_1task_highest

Experiments on working machine:
> BackgroundPagePriority-Default
> BlinkSchedulerHighPriorityInput-Control2
> BlinkSchedulerHighPriorityInputOnCompositorThread-Control
> BlinkSchedulerPrioritizeCompositingAfterInput-ImplicitSignals_3tasks_high
> DelayUnsafeAds-Control
> LowPriorityIframes2-Enabled_4G_Dogfood
> PdfIsolation-PdfIsolation_Dogfood
> VizHitTestDrawQuad-Control

Of these, the two that stand out are:

SitePerProcess-Control_25_20180606
VizHitTestDrawQuad-Experiment

Will try flipping some of these locally.

Still can't repro :(

There were some clues though. For one - on the broken machine, moving the mouse over text wouldn't change cursor, but we could still select text and click on links.

Comparing traces between the working and non-working version, it looks like in the broken case: mouse moves go to both the PDF tab's process as well as its mime handler. MouseWheel and GestureScroll events go to just the tab's process.

When things are working - it looks like all these events go to the mime handler process.

thestig@: Could you explain how input is supposed to flow between the various processes involved in a PDF document?

sadrul@: This sounds like an issue with process routing, that sounds like it would be related to viz hit testing issues? Anything above sound like it may narrow down what component might be breaking or where we should look next?

Hi, just received a notification stating "Your administrator is rolling back your device. All data will be deleted when the device is restarted.".

Is this somehow related to this issue? Also, since my machine is one of the few who consistently reproduce (and also because I don't want to lose all my data), is there a way for me to prevent this?

re: comment 37: I'm not clear on what happens between the browser and the renderer, and between the renderer and the guest view. The guest view runs pdf_viewer.js, and it has a chance to handle input events. Events that are not suppressed get forwarded to the plugin process, which then gets a chance to handle it as well.

re: comment 38: I don't think so? Ask your device administrator?

Ah ha, it's PDF Isolation.

Actually, maybe I got ahead of myself. Let me double check. The "good" news is I power washed my Chromebook and now I can repro this.

Re: isolation - there should be an about flag to play with this.

Re 39: I don't have a device administrator (or I'm the only one)... I could open another issue about this roll-back occurring out of the blue, but wanted to check here if its related.

If you get consistent reproduction, then I can go ahead and reboot my machine and see what happens (if it rolls back I imagine the issue will no longer reproduce).

Nope, false alarm. Not PDF Isolation. Since I have a repro now with 70.0.3538.7. I'll also try flipping my experiment flags and try to track down what's causing this.

re: comment 43 - Best to open another issue. I don't think that's got anything to do with this issue.

Re 44: Rebooted. No rollback occurred, and the pdf scrolling issue still reproduces.

P.S. (general): I would like to switch back to stable. Please let me know if my input / repros are still needed on this (in which case I'll keep my machine as it is).

Powerwashed the machine. Issue no longer reproduces.

Sorry I've been busy with my own projects :-)

I still have the issue with 70.0.3538.16

Searching for pdf in chrome://flags:
Click to open embedded PDFs  --> Default
PDF isolation --> Default
Use PDF compositor service for printing --> Default

First trace (10:44) was failing to scroll http://composter.com.ua/documents/Single_Root_IO_Virtualization_Configuration.pdf
Second trace (10:46) was succeeding to scroll a drive file

Variations	
2c707b42-ca7d8d80
411b6d4e-f23d1dea
b7d3b6c2-f23d1dea
fe69e053-f23d1dea
ec9e5e18-65bced95
9d7f502c-d5d68bac
d01ab0d3-2e200496
3e006338-3f4a17df
1a0d11d4-2f9febdf
e202a358-65bced95
16e0dd70-3f4a17df
66df3e9d-a85d0b2f
b7e2524c-502eac8f
a6674cf-4f295bf2
a07e695a-f23d1dea
3cd9377c-63f8c5f6
da89714-4ad60575
64da5c1e-5e8c63f
8982496f-ca7d8d80
b1681d28-1410f10
61832c80-f23d1dea
cc20827f-6463c988
9041608a-3f4a17df
5852bcb0-a75ab0e
9853922b-c200976c
ca05d627-3f4a17df
3e38f260-f8f5001
7c1bc906-86bf56d9
9def365c-f23d1dea
47e5d3db-3d47f4f4
125b7f68-65bced95
d442dfb7-41afa35c
9ca1387e-f23d1dea
71ed337-5b96f4bb
1149accc-65bced95
4dc30737-b8a5ea08
af59fc20-2599138c
34d450b1-5d0693b2
15d89564-80f9a33e
a582a1b8-ad75ce17
495970ba-ca7d8d80
7f7844ec-f23d1dea
3042ad4b-ca54bb47
ebbb4e0a-ca7d8d80
98be3390-54f732d1
267255c3-f4950e99
249dd49a-a102c38
116c6887-4d2fac87
44827ee5-43146c13
88a387d2-f0d95b7c
edbcf7c5-961c461c
5485fc4d-3f4a17df
93731dca-e89d496c
41f007f9-f23d1dea
9b4c4257-6ad6e56e
43f62d3b-f23d1dea
c992f345-ca7d8d80
165e16d1-3f4a17df
9e5c75f1-e406a769
6872f671-991e1e1
350fabdd-34b13816
6fa07eb4-b398aa14
34d9fc71-f23d1dea
f2fd8aaf-f23d1dea
4934552d-f23d1dea
2ca9c26b-3f4a17df
2fccc5d5-855be3dd
7a5ba892-3f4a17df
d1cd70a5-f6fbb08e
4ea303a6-7fa1197f
6e6e0c7e-f23d1dea
95876445-f2718d9f
d92562a9-65bced95
4da5ae82-91c810ef
2c1d398c-3f4a17df
de52c077-65bced95
cc54eb06-3f4a17df
58a025e3-36e97b2c
4932440-f23d1dea
df072bba-44dc0b8
8576baf1-f23d1dea
51b9b54d-65bced95
7345ea6-3f4a17df
344833e9-1525b35b
3f273a97-25a103a9
4bc337ce-87ea0e5e
553edbc3-65bced95
d1466cda-f23d1dea
9a2f4e5b-3fe9c4dc
494d8760-52325d43
3ac60855-3ec2a267
f296190c-7da8925a
4442aae2-e1cc0f14
ed1d377-e1cc0f14
12e17bc5-e1cc0f14
75f0f0a0-6bdfffe7
e2b18481-a5822863
e7e71889-e1cc0f14
f9e5da91-f23d1dea
6e3b857e-b94298be
6a51bb09-ca7d8d80
82ebe475-f23d1dea
cc73f8a1-a3a14831
b4e8892d-3f4a17df
8834fcca-cf4f6ead
81c6897f-3d47f4f4
3a17127a-870290a7

Deleted: trace_Fri_Sep_14_2018_10.44.31_PM.json.gz 10.6 MB

trace_Fri_Sep_14_2018_10.44.31_PM.json.gz 10.6 MB Download

Deleted: trace_Fri_Sep_14_2018_10.46.40_PM.json.gz 8.2 MB

trace_Fri_Sep_14_2018_10.46.40_PM.json.gz 8.2 MB Download

 Issue 879258  has been merged into this issue.

Turning "Viz Hit-test Draw-quad version" to Disabled fixed it for me.

thestig@, could you tell me how you repro the bug? I tested with VizHitTestDrawQuad before with 70.0.3532.8 on eve but wasn't able to repro

I'm on 70.3538.16 here. Just load a PDF and try to scroll. I suspect if you cannot reproduce it that easily, one possibility is this issue only manifests when there are a combination of flags. I can try flipping some other flags and see if anything else has an effect on this.

I tried a bunch of flags, but I haven't found another that would make this bug disappear while VizHitTestDrawQuad is enabled. This is on a caroline, BTW. I've also noticed with this bug, when I restart the browser from chrome://flags, the PDF tab that gets restored on restart actually works for a few seconds. Then the bug sets in and it stops working.

Attached are the variations on my affected Chromebook.

Deleted: variations.txt 1.6 KB

variations.txt 1.6 KB View Download

I also cannot reproduce even turning on the flag - however, all reporters that can reproduce and provided their variations show the experiment VizHitTestDrawQuad-Experiment so it sounds like a likely culprit.

"Viz Hit-test Draw-quad version" was default --> scrolling not working
I set it to Disabled --> scrolling worked.
I set it to Enabled --> scrolling stopped working.

 Issue 885277  has been merged into this issue.

still having trouble repro it locally, will disable VizHitTestDrawQuad finch on ChromeOS platform first

This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Issue 884477 has been merged into this issue.

 Issue 887165  has been merged into this issue.

 Issue 874106  has been merged into this issue.

Since it hasn't been patched, I'm sure it's no surprise but this issue still persists on 71.0.3558.0 on EVE.

I think I understand what is causing the issues and how we can fix it, although I can't explain why it repros only on some chromebooks and not others. Hopefully we will land a fix soon.

We did disable viz hit-testing in finch though, so if you reset the 'viz hit test' flag to default (in chrome:flags), then you should no longer see the bug.

oshima@, we found that on devices that we could repro this bug (e.g. eve and cave), there's an ExoShellSurface under SystemModalContainer that's transparent and on top so messed up with event targeting; on devices that couldn't repro (e.g. eve-arcnext), there's nothing under SystemModalContainer.

We were wondering 

1. What's the difference in device settings that would cause this difference about whether we have ExoShellSurface or not on difference devices? It would also be useful to know how to force this so we can repro this bug locally

2. Is it possible to just don't show ExoShellSurface here (https://cs.chromium.org/chromium/src/components/exo/shell_surface_base.cc?type=cs&q=exoshellsurface&sq=package:chromium&g=0&l=1214) since it's invisible anyway? Do you remember if we need it to be shown or not? 

Thanks!

Do you have a repro step? Can you also file a feedback so that I can look into logs?

I did find a similar isssue when I run CTS ( crbug.com/878426 ), but couldn't reliably repro it.

1) I guess it's due to finch experiment? Some device might have flag turned on, and others had off?
2) It is visible, in a sense that Android can create a layer at any time.

I'd like to understand the cause first before jumping into the solution. Please file a feedback and send it to me or post it here.

I found several interesting facts.
 1. The issue only happen after launching an ARC++ app. (It should be exo related)
 2. The scroll doesn't work in pdf viewer, but it works with regular web renderer. (PDF viewer is oopif I think).
 3. Only scroll events doesn't work, Other events (mouse, key) can work. (probably scroll events are not handled correctly but hit test)


FYI, [1] fixes a similar issues by setting up event targeting policy properly for all exo surfaces. I guess the issue could be because
chrome doesn't follow the event targeting policy for scroll events.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/667978

 Issue 889877  has been merged into this issue.

 Issue 889877  is mine. Acer Chromebook 14 board name Edgar. 


Followed instructions in Comment 12.
Variations:
2c707b42-ca7d8d80
411b6d4e-3f4a17df
b7d3b6c2-3f4a17df
fe69e053-f23d1dea
9d7f502c-d5d68bac
d01ab0d3-f23d1dea
16e0dd70-3f4a17df
66df3e9d-a85d0b2f
b7e2524c-300e5653
a6674cf-10e61f62
da89714-4ad60575
6c18ba9d-f23d1dea
64da5c1e-7bc2af31
8982496f-ca7d8d80
61832c80-3f4a17df
cc20827f-ca7d8d80
9041608a-3f4a17df
5852bcb0-a75ab0e
c6c1fc26-3f4a17df
9853922b-e3d9cd05
ca05d627-3f4a17df
7c1bc906-86bf56d9
9def365c-3f4a17df
62138821-3f4a17df
47e5d3db-3d47f4f4
125b7f68-3448ba33
d442dfb7-ca7d8d80
9ca1387e-f23d1dea
71ed337-3f4a17df
1149accc-3f4a17df
6557d030-f23d1dea
4dc30737-b8a5ea08
af59fc20-2599138c
34d450b1-6fa8045b
a582a1b8-ad75ce17
495970ba-ca7d8d80
7f7844ec-f34e292e
98be3390-d93a0620
e463c247-c40fe774
116c6887-9597b6c7
aa011017-a3a14831
44827ee5-f23d1dea
a7c9f607-1f56023b
edbcf7c5-adf3d98f
5485fc4d-3f4a17df
93731dca-3d47f4f4
41f007f9-41f007f9
9b4c4257-6ad6e56e
1b558915-f23d1dea
43f62d3b-1de29431
4ae380f4-3f4a17df
c992f345-ca7d8d80
3a0563a1-65222f0b
9e5c75f1-72b42aff
6872f671-991e1e1
2594bdf4-ed9a47bf
6fa07eb4-ca7d8d80
4934552d-3f4a17df
2fccc5d5-2fccc5d5
2b08b14-3f4a17df
7a5ba892-f23d1dea
d1cd70a5-5fd3e1a
4ea303a6-85fb2903
95876445-ca7d8d80
d92562a9-4d2fac87
fc369826-3f4a17df
67246da1-3f4a17df
cc54eb06-f23d1dea
58a025e3-36e97b2c
5e13f721-ba63a8c2
4932440-d21eb72d
df072bba-f23d1dea
8576baf1-f23d1dea
2e7f6029-9d04118c
344833e9-473e8c2e
3f273a97-e3ad1896
4bc337ce-87ea0e5e
553edbc3-3f4a17df
d1466cda-f23d1dea
9a2f4e5b-ca7d8d80
494d8760-52325d43
3ac60855-486e2a9c
f296190c-495cc57e
4442aae2-e1cc0f14
ed1d377-e1cc0f14
75f0f0a0-6bdfffe7
e2b18481-92bb99a9
e7e71889-e1cc0f14
f9e5da91-f23d1dea
6e3b857e-61c25c72
6a51bb09-ca7d8d80
b0ea13bc-3f4a17df
82ebe475-f23d1dea
cc73f8a1-a3a14831
b4e8892d-f23d1dea
81c6897f-3d47f4f4
3a17127a-3f4a17df

See attached file. Sorry for duplicating btw. I am new here and did not search deep enough. Thanks!

Deleted: trace_PDF_scroll_trace_edgar.json.gz 7.3 MB

trace_PDF_scroll_trace_edgar.json.gz 7.3 MB Download

 Issue 889066  has been merged into this issue.

Issue 877552 has been merged into this issue.

I can reproduce this again; including between restarts.
Took a trace this time. Also adding variations from chrome://version.

This is an eve on dev channel.

Version: 71.0.3558.0
Google Chrome	71.0.3558.0 (Official Build) dev (64-bit)
Revision	09438e58ad92274e6fa5f7a76429836ceeba5fa5-refs/branch-heads/3558@{#1}
Platform	11097.0.0 (Official Build) dev-channel eve
Firmware Version	Google_Eve.9584.171.0
Customization ID	GOOGLE-EVE
ARC	5024596

Deleted: trace_pdf-scrolling.json.gz 5.6 MB

trace_pdf-scrolling.json.gz 5.6 MB Download

Deleted: variations.txt 4.2 KB

variations.txt 4.2 KB View Download

Reliably reproduces when chrome://flags/#site-isolation-trial-opt-out is at "Default" and scrolling issue goes away when "opt-out".

Similar issues can be observed with 1Password X plugin not reacting to mouse clicks or iCloud.com being completely unresponsive to any mouse event.

Friendly ping, please provide an update on this issue. Is this still RBS (if not please remove the label)? When is the ETA on the work that needs to be done to resolve this? Thanks.

Adding site isolation label based on #76.

riajiang@ or anyone else: I see the title got renamed in #63, but can you clarify whether this bug affects only PDFs or OOPIFs in general?  AFAIK PDFs still use the BrowserPlugin infrastructure which isn't relying on OOPIFs yet (though ekaramad@ has work in progress for that).  Not being to interact with OOPIFs in general would be a pretty big deal.

Also, is this ChromeOS-specific, or does it affect other platforms?

I believe this is chromeos-specific, and does affect all OOPIFs (not just pdfs). There was an issue with viz-hit-testing and browser-plugin on other platforms that has already been resolved ( issue 880122 ). This seems to be different from that.

I fixed the issue on my device by forcing the viz-hit-testing flag to disabled and restarting chrome, as suggested in  issue 880122  (see #79).

The same goes for  issue 890308  where an iframe was not responding to mouse events. This is fixed by this flag as well.

Attached current variations.

Chrome 71.0.3558.0
11097.0.0 dev-channel edgar

Deleted: variations fix.txt 1.5 KB

variations fix.txt 1.5 KB View Download

Is this still happening on M70? It's marked as an RBS for M70 which is near Stable. Thanks.

It's not a RBS because the finch experiment has been turned off and the flag has been disabled by default. The last M71 dev version still had some problems because the flag was not disabled by default yet at that time, but after tomorrow's new dev version release, those problems should be gone.

I can verify disabling "Viz Hit-test Draw-quad version" as mentioned in #80 _also_ fixes the issue, while "Site Isolation trial opt-out" is set to Default. Reproduces between restarts of enabling and disabling as well.

71.0.3558.0 eve

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

commit 6b6c0f4696f58050525e022f598288a44710e6cc
Author: Ria Jiang <riajiang@chromium.org>
Date: Tue Oct 16 05:43:16 2018

Don't send events to windows that don't have TARGET event-targeting policy.

There are non-targeting windows that can still submit CompositorFrame,
set a flag when creating HitTestDataProviderDrawQuad to indicate
whether that window has TARGET event-targeting policy or not to
decide whether we should set Mine (accept events) or Ignore (reject
events) flag.

This is a speculative fix to  bug 877762 , with tests to show the
expected behavior.

Bug:  877762 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I6f9971daccffb3065abb984e1166eb266c5a9db2
Reviewed-on: https://chromium-review.googlesource.com/c/1260511
Commit-Queue: Ria Jiang <riajiang@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599871}
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/components/viz/client/hit_test_data_provider_draw_quad.cc
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/components/viz/client/hit_test_data_provider_draw_quad.h
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/components/viz/client/hit_test_data_provider_draw_quad_unittest.cc
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/components/viz/host/hit_test/hit_test_query_unittest.cc
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/components/viz/service/hit_test/hit_test_aggregator_unittest.cc
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/content/browser/renderer_host/compositor_impl_android.cc
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/content/renderer/mus/renderer_window_tree_client.cc
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/content/renderer/render_thread_impl.cc
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/services/ws/window_tree_unittest.cc
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/ui/aura/local/window_port_local.cc
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/ui/aura/mus/window_port_mus.cc
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/ui/aura/window.cc
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/ui/aura/window.h
[modify] https://crrev.com/6b6c0f4696f58050525e022f598288a44710e6cc/ui/compositor/host/host_context_factory_private.cc

tested on repro-device cave (ASUS Chromebook Flip C302) dev channel 72.0.3593.0 with VizHitTestDrawQuad turned on and OOPIFs worked as expected, requesting a merge back to M71, thanks!

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

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

Merge approved for ChromeOS M71

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

commit 44911459173949e3c307552ae4942a11ecac8581
Author: Ria Jiang <riajiang@chromium.org>
Date: Mon Nov 05 19:37:13 2018

Don't send events to windows that don't have TARGET event-targeting policy.

There are non-targeting windows that can still submit CompositorFrame,
set a flag when creating HitTestDataProviderDrawQuad to indicate
whether that window has TARGET event-targeting policy or not to
decide whether we should set Mine (accept events) or Ignore (reject
events) flag.

This is a speculative fix to  bug 877762 , with tests to show the
expected behavior.

Bug:  877762 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I6f9971daccffb3065abb984e1166eb266c5a9db2
Reviewed-on: https://chromium-review.googlesource.com/c/1260511
Commit-Queue: Ria Jiang <riajiang@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599871}
Reviewed-on: https://chromium-review.googlesource.com/c/1318435
Reviewed-by: Ria Jiang <riajiang@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#509}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/components/viz/client/hit_test_data_provider_draw_quad.cc
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/components/viz/client/hit_test_data_provider_draw_quad.h
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/components/viz/client/hit_test_data_provider_draw_quad_unittest.cc
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/components/viz/host/hit_test/hit_test_query_unittest.cc
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/components/viz/service/hit_test/hit_test_aggregator_unittest.cc
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/content/browser/renderer_host/compositor_impl_android.cc
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/content/renderer/mus/renderer_window_tree_client.cc
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/content/renderer/render_thread_impl.cc
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/services/ws/window_tree_unittest.cc
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/ui/aura/local/window_port_local.cc
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/ui/aura/mus/window_port_mus.cc
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/ui/aura/window.cc
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/ui/aura/window.h
[modify] https://crrev.com/44911459173949e3c307552ae4942a11ecac8581/ui/compositor/host/host_context_factory_private.cc

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

Commit: 44911459173949e3c307552ae4942a11ecac8581
Author: riajiang@chromium.org
Commiter: riajiang@chromium.org
Date: 2018-11-05 19:37:13 +0000 UTC

Don't send events to windows that don't have TARGET event-targeting policy.

There are non-targeting windows that can still submit CompositorFrame,
set a flag when creating HitTestDataProviderDrawQuad to indicate
whether that window has TARGET event-targeting policy or not to
decide whether we should set Mine (accept events) or Ignore (reject
events) flag.

This is a speculative fix to  bug 877762 , with tests to show the
expected behavior.

Bug:  877762 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I6f9971daccffb3065abb984e1166eb266c5a9db2
Reviewed-on: https://chromium-review.googlesource.com/c/1260511
Commit-Queue: Ria Jiang <riajiang@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599871}
Reviewed-on: https://chromium-review.googlesource.com/c/1318435
Reviewed-by: Ria Jiang <riajiang@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#509}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}