On the plus side, this only seems to affect High Sierra.

spqchan@, do you think you have time to look at this? Feel free to kick it back to me if not.

FWIW: it looks like this isn't triggered by NSWindowStyleMaskFullSizeContentView, it starts happening (on High Sierra only) when Chrome just uses the window content view instead of adding things to the window frame.

One easy way to "fix" it is to just disable custom fullscreen transition. It won't be as smooth but it won't look as bad either

Should we just go ahead and do that (for 10.13) so at least that lands before the branch cut?

I'm testing a CL to do that now.

Since you're doing that, just make 

-(BOOL)shouldUseCustomAppKitFullscreenTransition in browser_window_controller_private return false if the system is 10.13

Reassigning to sdy@ since he's working on it. Let me know if you have any questions.

Hmm, the native transition looks broken in a different way. See the attached screen recording (it's low framerate because I took it in a VM, but the top of the window looks the same on 10.12 on my machine).

Deleted: crbug_741478_native_fullscreen_transition.mp4 3.4 MB

	crbug_741478_native_fullscreen_transition.mp4 3.4 MB View Download

That's what I meant by "fix" in Comment #5
It won't be as smooth or fast as we want, but it won't be as broken.

Anyway, if we're fine with that landing before the branch cut, let me know

On real hardware, it actually feels pretty smooth to me. The title bar looks bad, though — it doesn’t seem like an improvement over the current state.

If fixing the appearance of the title bar during the native transition is easier than fixing the custom transition, it might be viable to just use the native one going forward. I’m curious what you think if you try it.

The custom transition fixes the title bar appearance so we're going to have to fix it regardless

Hmm, I was working on crrev/c/562603 today and it looks like it fixes the title bar issue. Here's what the native/custom transitions look like on 10.12 with that change.

Deleted: crbug_741478_custom_transition.mp4 660 KB

	crbug_741478_custom_transition.mp4 660 KB View Download

Deleted: crbug_741478_native_transition.mp4 993 KB

	crbug_741478_native_transition.mp4 993 KB View Download

Great! Looks like this issue is fixed then
I'll assign this bug back to you since it's related to  Issue 562603 .
Feel free to re-assign this bug back to me if otherwise

spqchan@: OK.

Quick update: the native transition is unpredictable wrt when it takes the screenshot and when it covers the window with the screenshot. You can see a flicker at the beginning of the attached video.

Sometimes the web page is seen at the target size for a frame before the transition starts, and less frequently the transition shows the web page at the original size until it completes. Still probably better than the current state for 10.13, I think? I think the root cause of that unpredictability is the same as  issue 617824 .

Deleted: crbug_741478_native_transition_jank.mp4 1.9 MB

	crbug_741478_native_transition_jank.mp4 1.9 MB View Download

You posted a screencast of the custom transition on #14
Are there an issues with it?

Also, it'll be great if you can show screencasts with something in the webpage

Sorry, those were on my dev machine (10.12). Attached a couple from 10.13, real web page. Are these helpful?

Deleted: crbug_741478_10.13_custom.mp4 2.3 MB

	crbug_741478_10.13_custom.mp4 2.3 MB View Download

Deleted: crbug_741478_10.13_native.mp4 2.5 MB

	crbug_741478_10.13_native.mp4 2.5 MB View Download

Ooooh gotcha. Yep, thanks! It's much better.

Anyway, it's a bit unreliable and will need some work but it's much better than what we currently have. 

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

commit 71aac2d2a2c3f52763834ea1a7b933702ba3b943
Author: Sidney San Martín <sdy@chromium.org>
Date: Fri Jul 21 17:19:52 2017

Disable custom fullscreen transition on 10.13+, fix titlebar appearance during the transition.

Bug:  741478 
Change-Id: I7b576273b0e7ec08af24291115db1c8e8f9b3da8
Reviewed-on: https://chromium-review.googlesource.com/581232
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Sarah Chan <spqchan@chromium.org>
Commit-Queue: Sidney San Martin <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#488687}
[modify] https://crrev.com/71aac2d2a2c3f52763834ea1a7b933702ba3b943/chrome/browser/ui/cocoa/browser_window_controller_private.mm
[modify] https://crrev.com/71aac2d2a2c3f52763834ea1a7b933702ba3b943/chrome/browser/ui/cocoa/framed_browser_window.mm

[Auto-generated comment by a script] We noticed that this issue is targeted for M-61; 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-61 label, otherwise remove Merge-TBD label. Thanks.

Your change meets the bar and is auto-approved for M61. Please go ahead and merge the CL to branch 3163 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid @(ChromeOS), govind@(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/+/7835d679f6fa93c28f3c498e845d6f97c0e3b07c

commit 7835d679f6fa93c28f3c498e845d6f97c0e3b07c
Author: Sidney San Martín <sdy@chromium.org>
Date: Tue Jul 25 16:48:34 2017

Disable custom fullscreen transition on 10.13+, fix titlebar appearance during the transition.

TBR=sdy@chromium.org

(cherry picked from commit 71aac2d2a2c3f52763834ea1a7b933702ba3b943)

Bug:  741478 
Change-Id: I7b576273b0e7ec08af24291115db1c8e8f9b3da8
Reviewed-on: https://chromium-review.googlesource.com/581232
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Sarah Chan <spqchan@chromium.org>
Commit-Queue: Sidney San Martin <sdy@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#488687}
Reviewed-on: https://chromium-review.googlesource.com/585289
Reviewed-by: Sidney San Martin <sdy@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#28}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/7835d679f6fa93c28f3c498e845d6f97c0e3b07c/chrome/browser/ui/cocoa/browser_window_controller_private.mm
[modify] https://crrev.com/7835d679f6fa93c28f3c498e845d6f97c0e3b07c/chrome/browser/ui/cocoa/framed_browser_window.mm

I'm running 62.0.3166.0 and the flash of old (or new) window content, plus the resize at the end, make the transition very janky. Is this what you see with your fixes applied?

https://drive.google.com/open?id=0BwcLL5PHtZQHU1ZyY0JLQXV4WDQ

As Mac 10.13 is not available from our end,could anyone from MTV team please look into this issue.
Adding 'TE-NeedsTriageFromMTV' label.
Thanks..!!

Reopening for TE-NeedsTriageFromMTV, and for answer to question in c#26.

sdy@ - gentle ping on question in c#26.

Sorry for the lag.

- The resize at the end is unrelated — I see it on 10.12 with stable, too. I'm not sure if it's a browser issue or a YouTube issue.

- The flash at the beginning *is* from this change, and you can see it in the screen recordings in c#18. I think that the root cause is the same as  issue 617824  (which I want to work on it this quarter).

…I'm not sure how to address the TE-NeedsTriageFromMTV.

I think it can be removed since you've confirmed the issue.

It sounds like we should also remove the RBS?

I think it's up to you — I agree with removing RBS if you compare with 10.12+stable and don't think this is too bad to ship. Fixing  issue 617824  should fix this the rest of the way.

Setting the milestone to M62 (at least for now).

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

commit d2f3e5933b3c9dab1b0f0fc3c5f1f3451cdffc4d
Author: Sidney San Martín <sdy@chromium.org>
Date: Thu Dec 14 02:00:28 2017

[Mac] Make synchronized content resize/repaint visually atomic.

NSDisableScreenUpdates() is advertised for making visually atomic changes that
affect multiple windows, but it it's also effective when multiple processes
have layers in the same window. macOS uses it to synchronize resizing of
out-of-process views like NSOpenPanel.

Leaving screen updates disabled for too long can create funky visual artifacts
within and behind Chrome windows if left on for too long. This waits to flip it
until a frame has been produced of the new size, and it's only on during the
(very brief) compositor swap.

Bug:  617824 ,  741478 
Change-Id: Id6ddfb8848342d6e4b148207a3f76125774081d6
Reviewed-on: https://chromium-review.googlesource.com/798774
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523982}
[modify] https://crrev.com/d2f3e5933b3c9dab1b0f0fc3c5f1f3451cdffc4d/content/browser/renderer_host/render_widget_host_view_mac.h
[modify] https://crrev.com/d2f3e5933b3c9dab1b0f0fc3c5f1f3451cdffc4d/content/browser/renderer_host/render_widget_host_view_mac.mm

Tested the issue on mac 10.13 high sierra using chrome M65 #65.0.3295.0 and issue recorded the behavior.

Attached screencast for reference.

@sdy-- Could you please check attached screencast and confirm us if this is the expected fix , so that we can add TE-Verified labels.

Thanks!

Deleted: 741478.mp4 654 KB

	741478.mp4 654 KB View Download

hdodda: this looks good! Thanks.