Not clear what the screenshot is showing. Normal debugging steps start with grabbing a trace to see what is happening. Are you seeing it smooth on the 2nd monitor while its janky on the first? That sounds like the UI is just not moving the position very much, cuz both monitors are drawn together by the display compositor.

Re #1: I was about to grab a feedback report in case that shows anything, but I can grab a trace if you prefer (which type? Input Latency? Rendering?).

Re the screenshot, notice the window-resize shadow around the edge of the work area - that's not part of the desktop background image.

I usually default to Frame Viewer for graphics stuff. It lets you look at the contents of frames.

> Re the screenshot, notice the window-resize shadow around the edge of the work area - that's not part of the desktop background image.

I see the border but I'm not sure what it implies for this bug.. sorry.

This may be related to multi-sign-in on ChromeOS; the spurious resize border moves if you switch to the other sign-in desktop.

Shall I grab a Frame Viewer trace and share it with you via Drive (guessing it'll be too big to attach?)

It'd be nice if you can shoot video next time. I'm on a slightly newer version but haven't seen such issue. (but still getting a lot of "Aw Snap!" though...)

Chrome: 58.0.3029.68 (Official Build) beta (64-bit)
Platform	9334.42.0 
stumpy

Doh, I might have looked at the wrong bug. It's older, so could be new issue.

Re #6: Shared a video w/ you and Dana directly.

FWIW this repros 100% reliably even after I log-off and sign back in, but it sometimes affects the primary monitor and sometimes the secondary.  I no longer have multi-sign-in so it's not related to that.

The video showed that wez is dragging the window around entirely on one monitor or the other, I misunderstood the initial report to be dragging it at the boundary between the two monitors. One monitor is fast one is janky, when moving around during the same drag to the other monitor.

Once the drag stops on the other monitor and starts again does it do the same thing or is it fast then?

Looks like it's the phantom window that is janky?

+reveman@, domlaskowski@ in case they have some ideas.

Re #9: If I drag a window so that it overlaps both monitors then it is janky on one of them and smooth on the other, regardless of which of the amount of the window area that is on each monitor. If you drag a window from one monitor to the other then it will go from smooth to janky or vice versa.

It doesn't repro on linux_chromeos build with --ash-host-window-bounds=800,0+800-800x800

Have you tried to repro on device oshima?

I tested 59.0.3064.0 on caroline, and didn't notice any jank. (will test with newer build later)

It's possible that it actually is the CompositorResizeLock, but there's no mention of it in the trace so that'd be weird, unless the ui category isn't included.

wez could u try a trace of the cc and ui categories and see what that looks like?

Also that would mean the ui is waiting on a frame of the right size from the renderer, but youre moving not resizing the window so that's odd?

Does this repro at 100% desktop zoom factor? What zoom are you using?

Frame Viewer doesn't include the 'ui' category by default.  Running a
Recording just now with FrameViewer+'ui' categories, I no longer get the
mysterious hang/jank when I hit Record, though. :(

This is with 100% desktop zoom (device is a Chromebox with external
monitors, so I don't think desktop zoom is even configurable).

My theory is there are DIP window sizes that don't quite match the pixelsize converted to DIP for the renderer frames, but idk.

New trace shows CompositorResizeLock is constantly being grabbed/timeout/grabbed. wez do you see this in traces even if you don't move your window onto the janky monitor?

FWIW I just tried reconfiguring my monitor dimensions, in case that causes
some internal device pixel ratio state to get nudged, and the issue is
still reproing.

Does this happen on Task Manager window? (I assume not, but want to double check)

It affects all windows on the affected monitor.  Danakj@ and I chatted a
bit via IM and I tried closing tabs to see if that helped - it seems that
the trigger for the jank was either a Docs tab, or an Extension tab that I
had open, though we still don't know why. If it happens again then I'll
check whether all the tabs are rendering correctly to see if that might
hint at the cause.

I can repro something by control-clicking links on slashdot, as they open background tabs that are never getting a frame, they thing they need a resize lock and forever grab them.

Alternatively, if a tab was resized, then backgrounded and evicted, and the renderer didn't get a frame to the browser of the right size before it was evicted, I think the same thing would happen. I can repro this also.

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

commit 8230eff799f34889d9ec93944a4e8f3147b91c17
Author: danakj <danakj@chromium.org>
Date: Sat Apr 22 00:24:16 2017

ui: Prevent DelegatedFrameHost from taking CompositorResizeLock forever

In the case where DelegatedFrameHost has no frame, it is not showing
a renderer tab contents, so it does not need to try prevent guttering.
However it would grab a resize lock still, in some cases where it will
never be receiving a frame from the renderer. When that happens the
lock times out after 67ms and it grabs it again.. forever. This causes
the UI to update at 15 fps instead of 60.

This fixes it by not allowing a resize lock to be grabbed when
|has_frame_| is false. And when |has_frame_| changes from true to
false, any current resize lock is dropped, freeing up the UI to
present itself.

R=fsamuel@chromium.org, nick@chromium.org
BUG= 712903 

Review-Url: https://codereview.chromium.org/2832043002
Cr-Commit-Position: refs/heads/master@{#466508}

[modify] https://crrev.com/8230eff799f34889d9ec93944a4e8f3147b91c17/content/browser/renderer_host/delegated_frame_host.cc
[modify] https://crrev.com/8230eff799f34889d9ec93944a4e8f3147b91c17/content/browser/renderer_host/render_widget_host_view_aura.h
[modify] https://crrev.com/8230eff799f34889d9ec93944a4e8f3147b91c17/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

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

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

commit 344425197d426ed2c3f3b5527a67f98fb0d483b5
Author: danakj <danakj@chromium.org>
Date: Tue Apr 25 21:07:53 2017

ui: Prevent DelegatedFrameHost from taking CompositorResizeLock forever

In the case where DelegatedFrameHost has no frame, it is not showing
a renderer tab contents, so it does not need to try prevent guttering.
However it would grab a resize lock still, in some cases where it will
never be receiving a frame from the renderer. When that happens the
lock times out after 67ms and it grabs it again.. forever. This causes
the UI to update at 15 fps instead of 60.

This fixes it by not allowing a resize lock to be grabbed when
|has_frame_| is false. And when |has_frame_| changes from true to
false, any current resize lock is dropped, freeing up the UI to
present itself.

NOTRY=true
NOPRESUBMIT=true
TBR=danakj
BUG= 712903 

Review-Url: https://codereview.chromium.org/2832043002
Cr-Commit-Position: refs/heads/master@{#466508}
(cherry picked from commit 8230eff799f34889d9ec93944a4e8f3147b91c17)

Review-Url: https://codereview.chromium.org/2840063002
Cr-Commit-Position: refs/branch-heads/3071@{#205}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/344425197d426ed2c3f3b5527a67f98fb0d483b5/content/browser/renderer_host/delegated_frame_host.cc
[modify] https://crrev.com/344425197d426ed2c3f3b5527a67f98fb0d483b5/content/browser/renderer_host/render_widget_host_view_aura.h
[modify] https://crrev.com/344425197d426ed2c3f3b5527a67f98fb0d483b5/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc