Unable to reproduce the issue on Win-10 surface pro using chrome reported version #68.0.3440.84 and latest canary #70.0.3515.0.
Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to a webpage, ex. https://en.wikipedia.org/wiki/Google_Chrome
2. Put Finger on touchscreen and hold it there
3. Tried scrolling and observed that page scrolled smoothly with the movement of finger without any issues.

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

Thanks...!!

Deleted: 871257.mp4 17.1 MB

871257.mp4 17.1 MB Download

Canary  70.0.3516.0 (latest version when testing) does this as well with no extensions and a clean profile.

Disabling hardware acceleration still removes the issue.

Putting windows into high performance mode also seems to workaround the issue. 
However Chrome is still the only application I can find with this behavior. 

Deleted: Google Chrome - Wikipedia - Google Chrome 8_8_2018 8_38_51 AM.mp4 9.8 MB

	Google Chrome - Wikipedia - Google Chrome 8_8_2018 8_38_51 AM.mp4 9.8 MB View Download

Scrolling is smooth with track pad.

Deleted: Google Chrome - Wikipedia - Google Chrome 8_8_2018 8_41_47 AM.mp4 8.4 MB

	Google Chrome - Wikipedia - Google Chrome 8_8_2018 8_41_47 AM.mp4 8.4 MB View Download

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

djvigli1@: Please capture a performance trace and attach it here. See instructions: https://www.chromium.org/developers/how-tos/submitting-a-performance-bug

Here is a performance trace of scrolling using touch on a web page.
Captured in Canary 70.0.3517.0

Deleted: trace_TouchScrollPerfTrace.json.gz 2.4 MB

trace_TouchScrollPerfTrace.json.gz 2.4 MB Download

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

Additionally here is one while scrolling with the track pad.
Also Captured in Canary 70.0.3517.0

Deleted: trace_TrackpadScrollPerfTrace.json.gz 4.3 MB

trace_TrackpadScrollPerfTrace.json.gz 4.3 MB Download

A Gentle ping...

@ bokan@chromium.org: As per comment #6 #8 #10,Requesting you to please have a look in to it for further inputs on it.

Thanks..!

Looks like the renderer's choking on long-running RenderAccessibilityImpl::SendPendingAccessibilityEvents tasks. Perhaps a dup of  issue 868830 ? Over to dmazzoni@ to check.

In the mean time, djvigli1@gmail.com: do you have any accessibility features enabled in chrome://accessibility/ ?

For accessibility features it's only the defaults already enabled in chrome,  Issue 868830  seems to highlight when "Text metrics" is enabled, which is not currently enabled in chrome for me. This scrolling problem I see is only exhibited when using the touch screen to scroll. 


I tested opening Canary 70.0.3521.0 with the "--disable-renderer-accessibility" flag; it still exhibits this behavior. Here is a Performance trace with accessibility disabled as well. 

Deleted: Chrome accessibility Defaults.png 214 KB

	Chrome accessibility Defaults.png 214 KB View Download

Deleted: trace_TouchScroll_NoAccessibility.json.gz 2.5 MB

trace_TouchScroll_NoAccessibility.json.gz 2.5 MB Download

Thanks for the trace, this new one does not have an issue with accessibility.

I see now there's periods of ~1 second where Chrome isn't receiving any touch moves between the start and end. In this trace, did you perform multiple scrolls? (i.e. tap, drag, release multiple times)? If so, could you record again with just one scroll and make sure not to stop your finger. I'd like to make sure the period without events isn't just me misreading the trace.

If you don't mind, a comparison trace with the same actions but when you have hardware acceleration disabled would also be helpful.

What do you do to disable hardware acceleration, is that a Windows setting or somewhere in Chrome?

I did scroll up and down multiple times, i can't remember if i lifted my finger. These traces are scrolling on the touch screen once down, then once up, as far as i could on the screen without lifting my finger in between, so a single event. 

To disable hardware acceleration I use the setting in Chrome's settings.

Deleted: ChromeSettings.PNG 25.6 KB

	ChromeSettings.PNG 25.6 KB View Download

Deleted: trace_SingleTouchScroll.json.gz 791 KB

trace_SingleTouchScroll.json.gz 791 KB Download

Deleted: trace_SingleTouchScroll_NoHWAcceleration.json.gz 2.2 MB

trace_SingleTouchScroll_NoHWAcceleration.json.gz 2.2 MB Download

The NextAction date has arrived: 2018-08-23

Any updates on this issue? It seemingly affects all surface go's and some other 2 in 1s like the hp spectre x360. Chrome is completely unusable on the surface go due to this and it seemingly effects no other browser. Stable, beta, dev and canary channels all share the issue.

Unfortunately not, we can't reproduce it on our end and don't have a device. I'll order a Surface Go this week and see if I can get to the bottom of the issue.

Just wanted to provide some additional info. When changing the ANGLE backend to opengl from dx11 in the latest canary the issue goes away completely.

The issue also does not happen when using dx9 for the backend.

Thanks for the additional info. Maybe someone from ANGLE team has a better idea what might be going wrong here?

Interesting that it improves with the OpenGL back-end. We might need to get a touch device to try and repro. I don't think we have one here right now.

I cannot confirm that the openGL back-end improves the issue. Attempting to start Chrome with '--use-angle=gl' argument results in a black screen, or terrible performance overall on my Surface Go

FWIW, I couldn't repro on any of our touch devices - it appears to be specific to the Surface Go with lots of complaints in https://www.reddit.com/r/Surface/comments/94bmqv/surface_go_chrome/

There's traces in #15. When I took a look, it seems that we go for long (~500ms-1s) periods without getting any events from the OS, indeed, there's no activity in any processes in those "dead regions". 

Changing the ANGLE back-end to DirectX 9 using '--use-angle-d3d9' also seems to workaround the issue, and touch scrolling works well. 

There seems to be some other 2 in 1 devices like the HP Spectre that are also affected. I'd guess touch devices with lower end Intel HD Graphics. 

CC'ing a few people from the Intel team. This might be an Intel driver bug.

I should have stated when I swapped to the opengl backend that I was using the latest intel gpu driver. If I use the driver the surface go shipped with then I get the black screen when using open gl. However when using the open gl backend with the newest intel driver the stops/freezes do not happen.

Assigning to Jamie so it stays on someone's radar.

Any movement on this? The issue still persists for EVERY surface go user.

This also is an issue for many HP Spectre x360 users

I am definitely not the right owner for this. Unassigning myself so the triage team can send this to someone who can act on this.

Geoff, could you take a look and/or triage? Maybe we should consider blacklisting d3d11 on some Surface devices?

Mo, any ideas here?  Could it be direct composition related?  I don't have one of these devices in house.

I tested on the Microsoft Surface Book that I have and I couldn't reproduce. On my Surface Book, direct composition is available, and we run on top of D3D11.

Bruce, since you have a Surface Go in house, can you take an initial look to see if you could reproduce this in house?

I doubt it's related to direct composition, but we can confirm by running with --disable-direct-composition.

djvigli1@gmail.com: can you give it a try and see if the problem is still there with the command line switch?

Actually, with the "--disable-direct-composition" switch, i seem unable to induce the problem on my Surface Go.
Tested on Canary 71.0.3578.0

Sunny and I took a look at the traces for trackpad and touch. The difference is for trackpad, we got mouse events in InputLatency, but we got touch events for touch in InputLatency. Sunny has a idea that Windows might detect if an app is outdated if it's using D3D9 and are not handling touch events, so OS will map to Mouse events behind the scene, that's why it runs fine with D3D9.

The bug seems to be we are not hooking up rendering with touch events correctly.

It's definitely not an ANGLE bug, but a bug related with touch input.

reporter: can you record the following traces with the same wiki page and same interactions? For tracing recording, select "Javascript and rendeirng", but in "Edit categories", enable "input."

1) Run Chrome with no extra commandline, use touch
2) Run Chrome with --disable-d3d11, use touch
3) Run Chrome with --disbale-gpu, use touch
4) Run Chrome with no extra commandline, use trackpad

Thank you!

Per #38, can you record an extra tracing:

5) Run Chrome with --disable-direct-compositing, use touch

Just to confirm our hypothesis. Thank you!

Here are traces using all of those scenarios. in each of them I scroll once down, basically the length of the screen, then back up to where I started. 

Deleted: trace_No_Command_Line_Touch.json.gz 1.4 MB

trace_No_Command_Line_Touch.json.gz 1.4 MB Download

Deleted: trace_No_Command_Line_Trackpad.json.gz 2.3 MB

trace_No_Command_Line_Trackpad.json.gz 2.3 MB Download

Deleted: trace_--disable-gpu_Touch.json.gz 1.6 MB

trace_--disable-gpu_Touch.json.gz 1.6 MB Download

Deleted: trace_--disable-direct-composition_Touch.json.gz 1.8 MB

trace_--disable-direct-composition_Touch.json.gz 1.8 MB Download

Deleted: trace_--disable-d3d11_Touch.json.gz 1.7 MB

trace_--disable-d3d11_Touch.json.gz 1.7 MB Download

Thank you for gathering the data for us.

So it seems when we run chrome in regular mode (without extra command line switch) using touch screen, in the time frame of 0.6 seconds, we get roughly 10 touch events (in the browser main thread, GestureProvider::OnTouchEvent()).

However, the three runs with --disable-direct-composition, --disable-gpu, --disable-d3d11, in the same 0.6 seconds time frame, we get hundreds of the same touch events GestureProvider::OnTouchEvent().

I have no idea where these events disappeared, or why the three switches trigger a difference. One thing for sure, this is not a bug in Chrome's GPU implementation.

It seems more appropriate for input folks to take a look at this.

dtapuska@: can you triage? 

Over to bokan@ to triage

I wonder if this has anything to do with using DirectManipulation APIs.

Marking as blocking the "master" Windows scrolling smoothness bug - thanks for the report.

I would like to figure out why we got hundreds of same touch event at 1 frame first.

With DirectManipulation APIs, we can control the event stream rate but we need to find out how to fallback to touch event since we expose touch event to JS.

No, not 1 frame, but during 0.6s time frame

I did some investigating on this issue.

On Surface Go, Windows stop send WM_POINTER events eveny ~0.5s for ~0.5s (See tracing file MessagePumpForUI::ProcessMessageHelper).

I have check following but not fix this issue:

1. Use WM_TOUCH instead of WM_POINTER
2. Remove DirectManipulation API
3. confirm MessagePumpForUI was running at that 0.5s
4. Change battery setting to best performance

I have tried use spyxx to hook up chrome's events but not able to get any message.

brucedawson@ do you know other thing may cause this?

Deleted: trace_1 (1).json.gz 767 KB

trace_1 (1).json.gz 767 KB Download

+cc brucedawson@ for #51

Just tried run Chromium 40.0.2193.0, it works well. Maybe we can find the bug by bisect.

I can reproduce the problem on my Surface Go laptop. I've noticed that when Chrome stops receiving the messages and stops scrolling this gap is always between 700 and 720 ms in length, at least for the six gaps in the trace that I'm looking at. During those gaps Chrome is almost completely idle, often using less than 1% of a core across all Chrome processes.

I think the trick with spyxx is you have to be sure to run a copy that is the same bitness of Chrome, so the 64-bit version for the 64-bit version of Chrome.

--disable-direct-composition does seem to solve the problem, but my guess is that there is some sort of secondary effect there rather than an actual problem with direct composition. It's also odd that even without --disable-direct-composition 

Unfortunately I don't know much about Chrome's input processing or Windows touch event processing.

I got a reply from Ross from Microsoft:

---
I’m seeing the same signs that we were seeing in VSCode – the speed hit-test is finding a window in one chrome process [A] (class “Intermediate D3D Window”), but the secondary hit-test once inside that process is finding a different one in a different chrome process [B] (class “Chrome_RenderWidgetHostHWND”, title “Chrome Legacy Window”).

We fixed one bug on the OS side that was causing issues here, but it seems like there’s another. What’s happening is that there’s a lock on the input queue, shared by both [A] and [B]. When [A] is woken up for input (as it’s getting the touch input first), it’s supposed to grab the lock, redirect the input to [B], and release the lock. When [B] wakes up, it grabs the lock, processes the input, and releases the lock.

Crucially, [B] only releases the lock once it’s done processing the current input – that is, when the kernel implementation of GetMessage() is called. If [A] gets a new input message in this time frame, it will be unable to acquire the queue lock, since [B] is still holding it, and the input will be left in the queue. It’s here that we end up in a bad state… I see that after this occurs, the input stack simply starts coalescing the touch input, as if [A] simply hadn’t gotten around to waking up to process it yet. But the truth was that [A] had been woken up, it just wasn’t able to dequeue the input.

There could be two problems here:

[B] is holding onto the lock longer than it should
[A] isn’t being woken up again after its first failure to retrieve the message

I can’t see the lock state in the trace, but signs point to #2 – I don’t see [A] running at all while the input is getting coalesced, so it’s not continually trying and failing to access the queue.

I’ll open a bug on the OS side to get this looked at, but Chrome really shouldn’t be ending up in this state in the first place – even if this bug were fixed, it’s still a performance degradation to have the input stack route to [A] and then redirect to [B] for every single input report. Note that this was never fixed in VSCode – they still hit it, but we fixed an OS bug where [B] was never unlocking the queue for PTP input, making the problem significantly more severe. This seems to have been enough for VSCode, though it’s likely that this new variant can affect them as well.

So my recommendation is to figure out why this window is getting hit-tested, and stop it. I know that for VSCode, there’s some issue with them where some window reparenting isn’t occurring properly when maximizing the window. I don’t know if that’s what’s happening here for Chrome. If you can spend some time investigating VSCode, I’d appreciate it – they claim to be using an unmodified version of Electron that contains your earlier fixes for similar issues.

For Ross's investigation it seems like the UI events hit tested to D3D Window. Run with no-gpu/disable-direct-composition flags because we don't have D3D Window. Previously I fix a similar issue because the D3D Window z-order is higher than legacy window.

I double checked ToT, I don't see the D3D Window is higher than legacy window. I also don't see it change when user interacting. Is it any other case can make the event hit test to the D3D window?

brucedawson@ WDYT. Also could you please add Windows message loop expert to this issue.

> the speed hit-test is finding a window in one chrome process [A]
> (class “Intermediate D3D Window”), but the secondary hit-test once
> inside that process is finding a different one in a different chrome process

Can you (or Ross) explain this more? What is the "speed hit-test" and what is the "secondary hit-test"? Are these Windows constructs, or Chromium constructs? I'm not sure how we can fix the hit testing without knowing how it behaves and how it is that it gets different results in different contexts.

That is, I agree that the problem is that the wrong window is getting hit tested but I'm not clear on how that should be investigated and fixed.

Are there any recommended techniques for investigating what is going on here? Spy++? Do we need to instrument our message loops? Visualize the window depth order? Parenting structure?

I installed Spy++ on my test machine (as part of the C++ toolset of Visual Studio, although I probably could have copied it over) and when I drag the Find Windows tool over Chrome it says the class of the window that it found is Intermediate D3D Window, owned by the GPU process.

With I add --disable-direct-composition and do the same thing then the window that I find has the class Chrome_RenderWidgetHostHWND (title Chrome Legacy Window) and its owner is the browser process.

Is that the problem in a nutshell?

I don't know how spy++ select window. I also see spy++ select D3D Window each time I use Find Tool. With "disable-direct-composition" Chrome window don't have D3D window. 

MSDN only mention the spy++ shows window by z-order.
https://docs.microsoft.com/en-us/visualstudio/debugger/windows-view?view=vs-2017

We do create an intermediate window for DirectComposition in the GPU process:

https://cs.chromium.org/chromium/src/gpu/ipc/service/child_window_win.cc?rcl=290959673f4e335d0e84443224712af0c2518813&l=73

We do this because the DirectComposition target can only be created for a window owned by the calling process.  But comments here indicate that we move it behind the main window to avoid losing messages:
https://cs.chromium.org/chromium/src/ui/gfx/win/rendering_window_manager.cc?rcl=290959673f4e335d0e84443224712af0c2518813&l=58

I understand this will be the case in general once viz OOP-D (display compositor in GPU process) ships (maybe for software rendering mode only?). 
 +kylechar@ to confirm.

I played around with Spy++ on my workstation with --enable-direct-composition-layers, and I can confirm that the intermediate D3D window is at the top.  I believe the ordering between Chrome_RenderWidgetHostHWND and the D3D window calls to SetWindowPos changed at some time or there's a race.  We can try changing the SetWindowPos call here to specify HWND_TOP (or HWND_TOPMOST) and see if that fixes the problem:

https://cs.chromium.org/chromium/src/content/browser/renderer_host/legacy_render_widget_host_win.cc?rcl=4bf9d01dbf34f17c899095a937dabbb884ec87fe&l=135


Note: We recently disabled direct composition except on devices with hardware overlays so you need to pass in the --enable-direct-composition-layers flag for testing.

With OOP-D there is a child HWND for direct composition (which is the same as before) and for software composited windows that don't need to support transparency (which is new). For software composited windows that do support transparency, eg. the omnibox popup, there is no child HWND with OOP-D because the layered window API is used.

From Ross:

> Interesting update – turns out that my repro app does repro the problem! 
> I added some instrumentation, and it turns out there’s a maximum amount
> of coalescing that can occur, after which the input stack will generate
> new messages regardless. My 500ms timer masked that issue – I lowered
> the timer to 50ms, more than enough to hit the race, and the correct
> thread does not receive input every 50ms, due to the locking issue on
> the input queue.
> 
> Without being able to have you collect a trace for me, I’d guess that’s
> the same issue here – we eventually time out and stop coalescing, which
> finally wakes up the correct thread again.
> 
> Unfortunately, that means that neither of these is a Chrome issue. The
> only workaround you have right now is disabling direct composition, I
> suppose.

Microsoft folks confirmed this is Windows' issue, nothing we can do except disabling the direct composition. They will take care of the fix after that Bruce can request a back port.

This issue's pattern is in all Windows. But only low-end model actually seeing this issue. sunnyps@ can we disable direct composition for some model eg. Surface Laptop and Surface Go or disable based on CPU?

This is NOT isolated to low-end machines. I and a LOT of other users are experiencing the issue on the HP Spectre x360 with the i7-8550u and GeForce MX150 GPU.  Doesn't seem like a low-end config to me.

Posts back to 6/12 here: https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/chrome/nPhw1VC4mf8/LMWaBZz1AAAJ

Disabling direct composition will have dramatic power regression on Chrome.

chaopeng@: can you communicate further with Microsoft to understand better the nature of this bug and if there is a way for us to work around it before they fix the issue? Disabling direct composition will kill Chrome power efficiency for many users while they watch videos (and watching videos is most common user scenario). Specifically, how Edge is able to use direct composition and not affected by this bug.

I have created a support request (Support request 118102319261127) which will be our formal way of requesting workarounds, fixes, back ports, etc.

However, this process is always slow. We have to expect that it will be several months before there is any chance of a Windows fix. In the interim we will have to try creating workarounds. One obvious one is to disable direct composition on machines running RS4 or greater that have touch screens. That is probably a large percentage of Windows 10 customers, but at least it's not all of them.

Disabling for low-end machines seems dodgy since I would assume that the exact repro is very timing dependent and therefore may depend on power state, CPU load, and many other factors.

If we could detect when the problem is happening - or when the user is touch scrolling - and then disable direct composition then that would be nice, but I would imagine that dynamically turning off direct composition would come with significant issues and might break scrolling differently.

A Surface Go is relatively inexpensive so any teams looking at this should consider ordering one.

Based on louisd@ comment, it is a common issue not only in low end devices.

We can actually detect this issue by comparing the timestamp with last touch event in same touch event sequence. But after that can we store the state locally and disable direct composition in next time chrome start?

Please also see  crbug.com/897662 

If we disable direct composition: we regress power performance playing video dramatically, and we can't Min/Max/Close window

If we don't disable direct composition: we have the touch screen scroll issue here

We don't really have a workaround by simply disabling direct composition

The work around has to be fixing the window z-order

I'm seeing interesting results on a Lenovo Yoga Touch 710:

1) Default (direct composition enabled): window buttons work on touch
2) --disable-direct-composition-layers: window buttons do not work at all on touch (don't change visual state)
3) chrome://flags set windows10-custom-titlebar to Disabled: window buttons do not work but change visual state on touch
4) chrome://flags as above and --disable-direct-composition-layers: window buttons work on touch

So it looks like window buttons work on touch = direct composition xnor custom titlebar

Any reason why both edge and firefox don't share this issue? Do neither of them use direct composition?

Because they don't have 2 child windows in top window. See #55

I don't have any hardware that reproduces this problem. Can someone test if OOP-D with software compositing hits this bug too? Adding the flags --enable-features=VizDisplayCompositor --disable-gpu will enable OOP-D and force software compositing.

Kyle, I do not have the issue with those flags. 

kylechar@ OOP-D doesn't have this issue. Tested on Surface Go.

Interesting, thanks for checking. It looks like spy++ is finding the "Intermediate Software Window" HWND with OOP-D software compositing, so the same child window ordering problem seems to exist, but it's not causing the input event problem.

Ross suggest us using "WS_EX_LAYERED | WS_EX_TRANSPARENT | WS_EX_NOREDIRECTIONBITMAP" to fix this issue.

The first two should make the window transparent for input, and the third avoids allocating a bitmap that would otherwise be allocated with WS_EX_LAYERED (and is only necessary if using Gdi objects with the window).

That makes sense since WS_EX_TRANSPARENT is supposed to block input (I thought that was the case for all windows - layered or not).  Anyway if we want to use layered window, we'll have to use UpdateLayeredWindow instead of handling WM_PAINT, and we might be able to do that on GPU main thread I think?

Ah, it blocks input only for layered windows, but changes paint order for non-layered windows:

"Hit Testing
Hit testing of a layered window is based on the shape and transparency of the window. This means that the areas of the window that are color-keyed or whose alpha value is zero will let the mouse messages through.

If the layered window has the WS_EX_TRANSPARENT extended window style, the shape of the layered window will be ignored and the mouse events will be passed to the other windows underneath the layered window."

and

"WS_EX_TRANSPARENT
0x00000020L
The window should not be painted until siblings beneath the window (that were created by the same thread) have been painted. The window appears transparent because the bits of underlying sibling windows have already been painted.
To achieve transparency without these restrictions, use the SetWindowRgn function."

I added these 3 styles on Surface Go. The touch events looks good. And I don't see any render problem at simple page.

It seems we can still use WM_PAINT:

UpdateLayeredWindow always updates the entire window. To update part of a window, use the traditional WM_PAINT and set the blend value using SetLayeredWindowAttributes.

We assume the default color key for transparency is black.  I guess the defaults are same for layered windows as well.

Please make sure you test with --enable-direct-composition-layers, and also test resizing the window.  You should also notice that the minimize/maximize/close buttons won't work after the fix (this is a known bug).

 

Thank you sunnyps, it also works for resizing the window.

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

commit 69f83ca4122cc656480439d58afa0d2f656e3dc5
Author: chaopeng <chaopeng@chromium.org>
Date: Fri Oct 26 13:25:54 2018

Add window styles to avoid events hit test to wrong window.

Based on Windows folks reply, this scroll lagging issue is because the
message hit test to wrong window (Intermediate D3D Window) and need to
forward to the correct window (Chrome Legacy Window), but Chrome Legacy
Window is holding the input queue lock so Intermediate D3D Window can
not forward the message.

This fix adding 3 window extended styles to Intermediate D3D Window:

WS_EX_LAYERED | WS_EX_TRANSPARENT | WS_EX_NOREDIRECTIONBITMAP

The first two should make the window transparent for input, and the
third avoids allocating a bitmap that would otherwise be allocated with
WS_EX_LAYERED.

WM_PAINT, WM_ERASEBKGD and ClearInvalidContents() also removed because
they unnecessary for transparent layered window.

Bug:  871257 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: Ic708b4d2a5a37f8e2e98e425c1be8b28de41d001
Reviewed-on: https://chromium-review.googlesource.com/c/1299342
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#603073}
[modify] https://crrev.com/69f83ca4122cc656480439d58afa0d2f656e3dc5/gpu/ipc/service/child_window_win.cc
[modify] https://crrev.com/69f83ca4122cc656480439d58afa0d2f656e3dc5/gpu/ipc/service/child_window_win.h
[modify] https://crrev.com/69f83ca4122cc656480439d58afa0d2f656e3dc5/gpu/ipc/service/direct_composition_surface_win.cc

Not regression after the fix landed a week.

I heard back from Microsoft and they said:

"""
The workaround from Chrome’s end : https://chromium-review.googlesource.com/c/chromium/src/+/1299342 is recommended for now in the existing OS.

We are introducing changes in the next version of Windows (19H1), which will make sure the issue does not happen. For RS4 and RS5, a change is still under review because, with the workaround (https://chromium-review.googlesource.com/c/chromium/src/+/1299342), the issue would not happen in those versions and implementing any OS-wide changes under these existing OS requires additional care so as to not break the existing functionalities.

So, in conclusion, we have a fix for 19H1 but in the existing RS4 and RS5 OS, we recommend the workaround from Chrome’s end.
"""

 Issue 923193  has been merged into this issue.