Filed a feedback report in case logs contain anything helpful; I see a load of GLES errors, but judging by the logs, those are actually normal...

It sounds like a surface identity and/or sync problem.

Do you have a particular repro case? I haven't experienced this. URL? screen capture of the bug etc.

Also, there was a known issue that was fixed yesterday. This problem is likely fixed with this CL: https://chromium-review.googlesource.com/c/chromium/src/+/872454

I would sync with tip of tree. 

I had been using DevTools, but not at the time the issue occurred.  This
device runs dev-channel, so I'm limited to whenever we push fixes to that.

No reliable repro case. I did notice it seeming to happen a little more
often with Chrome Remote Desktop, but I'm running with SurfaceLayer video
playback enabled, so that may have been an unrelated issue.

I guess I'm saying I believe the bug might already be fixed. Please follow up after your build is updated.

Have you seen this bug recently?

Re #7: Yes, I saw it three days ago, on dev-channel. :) I also saw it again today, just now, with a GMail Tasks pop-out window, in ChromeOS 65.0.3322.0 (Official Build) dev (32-bit).

I am running w/ SurfaceLayer video rendering enabled, right now, but the windows I see freezing aren't ones containing video - is it possible, though, that identities are getting confused between WebContents, triggered by something in SurfaceLayer?

Any update on this? 

It is marked as a beta blocker for 65, and the beta promotion date is only a week away.

FYI, I also filed  issue 805995  for what looks like janky animation due to compositor frame timeouts, possibly related?

wez@: is this particular beta blocking issue still happening?

FYI, just encountering this on ChromeOS 65.0.3322.0 (Official Build) dev (32-bit), with a "desktop PWA" (chrome://flags/#enable-desktop-pwas).

Aside from a lot of "OnDidStopLoading called twice" messages, I don't see anything in any logs or traces to hint at why things sometimes stop updating. :(

We need to promote to beta soon, is there any chance we can get this fixed in the next couple days?

I haven't been able to repro this and I haven't seen other reports of this. As discussed with wez@, I'm removing the ReleaseBlock-Beta label. I'm replacing it with a ReleaseBlock-Stable. I'm hoping we will have a reliable repro once more users get this rev.

I've not been able to repro this locally for the past few days, but today I re-enabled Browser + GPU Out-Of-Process Heap-Profiling (to debug unrelated issue) and I've started noticing things occasionally stop updating (a couple of times Chrome Remote Desktop, and a couple of times other random tabs).

Still can't see any discernible pattern. OOP HP may be a coincidence, or given the performance impact, may be a trigger for some unusual race-condition?

Any recent repros? I'm just pinging this one occasionally because I don't have anything actionable here yet.

Re #16: I've found a 100% reliable repro for this issue under 65.0.3325.9 (Official Build) dev (64-bit) on a device with two monitors:

1. Launch Chrome Remote Desktop.
2. [optional] Connect to a host, with automatic resize-to-client enabled (the default for Windows & Linux hosts, IIRC).
2. Drag the CRD window to the other monitor.
3. Double-click in the CRD window titlebar to maximize it.
4. [optional] Interact with CRD.
5. Restore the window, either by double-clicking the titlebar, or clicking maximize control.

At this point the CRD window appears to be unresponsive:
- If you performed step #2 then the remote desktop continues to be displayed at the "restored" rather than "maximized" size, as though it hasn't resized-to-fit.
- If you did not perform #2 then you'll be at the host-list screen; none of the hosts will highlight when you hover over them, and if you click to connect to one then it will seem that nothing has happened.
- If you move the mouse over the window controls (minimize, maximize, close) at the top-right of the CRD window then they do not highlight.

If you then restore the window at #5 then whatever you did at #4 (e.g. connecting to host) will then be displayed.

And apparently this is even easier to repro than that:

1. Open a bug in crbug.com.
2. Drag the window to the second monitor.
3. Maximize the window.
4. Try scrolling w/ scrollwheel.

At this point the window will be unresponsive.

5. Now open a new window with crbug.com, and this time find a bug and click in the Add A Comment area, so that there is a flashing cursor.
6. Drag the window to the other monitor.
7. Maximize it.
8. Use the scroll-wheel on it.

You'll find that the window remains responsive in this case.

Let my device update to 65.0.3325.56 (Official Build) dev (64-bit) and verified that the issue still repros for me.

This applies to any platform where surface synchronization is enabled in M65: Window, Linux, Chrome OS.

This bug should be fixed as of this CL:

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

It will make its way into M65 beta next Wednesday. I will keep the bug open until then then I'll ping wez@ to see if he is still able to repro or not...

The NextAction date has arrived: 2018-02-15

The fix is in 65.0.3325.73. I'm reassigning to wez@ to confirm that the problem is gone. M65 is going stable soon!

My device is still running 65.0.3325.65 (dev-channel), with no updates pending - it looks like the next dev-channel release will be based on M66, so I don't think I'll be able to verify that it's fixed in M65.

govind - can we make sure that this gets verified by ChromeOS QA on Beta or Stable?

Assinging to  bhthompson@ (Chrome OS M65 TPM)

songsuk@, would it be possible for you to verify this?

This looks like it should be in OS 10323.30.0, Chrome 65.0.3325.65, so it should be out there to verify easily.

Re #26: Thanks for pointing that out. I've just tried the trivial repro steps that showed the issue in the past and sure enough I can't now repro it.

Hurrah!

[Auto-generated comment by a script] We noticed that this issue is targeted for M-65; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-65 label, otherwise remove Merge-TBD label. Thanks.

This CL has already been merged back into M65. Removing the Merge-TBD label.

Interesting, I am on 10323.30.0 with chrome 65.0.3325.65. Dragging this tab maximized to another screen creates a maximized window which contents don't repaint.
Is the root cause the same? If so, I'll mark my crbug/813157 as a duplicate of this one.

I don't know if they're the same bug. I'll grab crbug.com/813157 and investigate! Thank you!

I'm not able to reproduce the issue on Chrome 65.0.3325.85/10323.38.0 - Caroline/Mickey. Since I don't have a "Dual Monitor", use the "Chrome Remote Desktop".

Steps : 
1. open crbug.com on Caroline device 
2. Launch Chrome Remote Desktop and share the desktop between Caroline and Mickey devices
3. maximize the window 
4. try scrolling with Scrollwheel/touchpad from both Caroline and Mickey
Then, able to see the page scrolling on both devices

5. try to switch the tabs or double-click the titlebar to maximize/restore the window
Then, able to switch the tabs or maximize/restore the window from both devices.

Re #34: As per my comment #18, it's necessary to drag the window to a second monitor, before maximizing it, to repro the issue.

I'll try the comment#18/#35 once I get a dual monitor. 

Checked the issue with extending monitor(HP LP2465).  I'm able to reproduce the issue on 65.0.3319.0/10302.0.0(KIp). Unable to reproduce the issue on 65.0.3325.89/10323.39.0. 

Steps :
1. Open crbug.com
2. Drag the window to the extending monitor.
3. Maximize the window.
4. Try scrolling w/ scrollwheel.
Then, unable to scroll the page on 65.0.3319.0.   Able to scroll the page on 65.0.3325.89/10323.39.0(Kip). 

Thanks!

Just had to switch back to a ChromeOS beta-channel device running 65.0.3325.107, and observed this issue again, though only with a slightly more specific set of repro steps:

1. Open a browser window and maximize it.
2. Grab the tab and drag it to the other monitor.  It should maximize itself again.
3. Use the scroll-wheel to try to scroll the tab, or interact with the content some other way.

At #3 the tab will appear unresponsive, as before.  Restoring and re-maximizing will show the results of any interactions, and un-stick it.

Does this repro with M66? 

Re-closing; what I'm seeing is issue 813157.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-65; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-65 label, otherwise remove Merge-TBD label. Thanks.