Update:

This is a Regression issue seen from 'M-69' and providing the bisect info below:

You are probably looking for a change made after 576532 (known good), but no later than 576533 (first known bad).

CHANGE-LOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

https://chromium.googlesource.com/chromium/src/+log/ed9ddcaef93429474b18266245e9662cb375cb0b..1406837c85633743729c75ec61f02e45b852f1f2

Suspect: https://chromium.googlesource.com/chromium/src/+/1406837c85633743729c75ec61f02e45b852f1f2

@weili: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

NOTE: Issue is not seen on Win (7, 8, 8.1, 10) & Linux (14.04 LTS) OS.

Kindly refer the screen-cast attached previously.

Thank You..!!

 Issue 865658  has been merged into this issue.

sdy@, I am ooo now, can you pls take a look? This is pretty bad. If you have time to figure out how to do this (sliding top ui) correctly, pls help; otherwise we may need to revert my recent change. thanks.

"RBS" as this is P1 blocking MacViews launch.

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

commit e1de0d7e6291fbf9fc33643f002aec0fa4c10191
Author: Sidney San Martín <sdy@chromium.org>
Date: Tue Jul 24 13:20:34 2018

[Mac] Fix overlapping controls when menu bar is visible in fullscreen.

When the mouse is at the top of the screen in fullscreen and the toolbar
is visible, the toolbar slides down to make room for the menu bar. The
offset was calculated in GetBoundsForTabStrip(), which only affects some
of of layout. This change moves it to GetTopInset().

Bug:  865901 
Change-Id: I5de02ac951f8347aeadc4af7238ea8f9172edc68
Reviewed-on: https://chromium-review.googlesource.com/1147477
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577503}
[modify] https://crrev.com/e1de0d7e6291fbf9fc33643f002aec0fa4c10191/chrome/browser/ui/views/frame/browser_non_client_frame_view_mac.mm
[modify] https://crrev.com/e1de0d7e6291fbf9fc33643f002aec0fa4c10191/chrome/browser/ui/views/frame/browser_view_layout.cc

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

Let's try this on tomorrow's Canary before merging.

Hey sdy@. Thanks for fixing this. I checked latest Snapshot #577525 and it seems that your CL has removed one of the intended fixes from https://chromium-review.googlesource.com/c/chromium/src/+/1142694:

The web content is again moving down, when the Menubar/Toolbar slides down :(

Here is a screencast.

Thanks for checking it.

Deleted: Content_moving.mov 1.7 MB

	Content_moving.mov 1.7 MB View Download

The NextAction date has arrived: 2018-07-25

I'm working on a more thorough fix.

Thank you :)

Update:

Rechecked the above issue on latest Canary version 70.0.3503.0 on Mac (10.12.6, 10.13.1, 10.13.6, 10.14) and the original issue is found Fixed. Hence, adding the respective labels.

Please refer the attached screen-cast.

Thank You..!!

Deleted: Fixed Video.mov 2.1 MB

	Fixed Video.mov 2.1 MB View Download

sday@, per comment #14 you're working on a more thorough fix. Pls request a merge to M69 once change is landed/baked/verified in canary. Thank you.

govind@: The current behavior is not perfect as mentioned in #12, but it's better than what's currently on beta. I'd be okay with closing and merging this fix and opening a second bug to track the better fix. Thoughts?

Re #20: Yes, I'm ok with it. ellyjones@ are you ok with it?

#20 #21: That is okay with me - this bug is worse than the bug reintroduced by the simpler fix.

Tracking remaining work in issue 868382.

Approving merge to M69 branch 3497 based on comment #20 and #22. Please merge. Thank you.

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

commit fa2a40240c78edaf9dacbc7ff8df6c0f33373f78
Author: Sidney San Martín <sdy@chromium.org>
Date: Fri Jul 27 15:35:11 2018

[Mac] Fix overlapping controls when menu bar is visible in fullscreen.

When the mouse is at the top of the screen in fullscreen and the toolbar
is visible, the toolbar slides down to make room for the menu bar. The
offset was calculated in GetBoundsForTabStrip(), which only affects some
of of layout. This change moves it to GetTopInset().

Bug:  865901 
Change-Id: I5de02ac951f8347aeadc4af7238ea8f9172edc68
Reviewed-on: https://chromium-review.googlesource.com/1147477
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#577503}(cherry picked from commit e1de0d7e6291fbf9fc33643f002aec0fa4c10191)
Reviewed-on: https://chromium-review.googlesource.com/1153107
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#153}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/fa2a40240c78edaf9dacbc7ff8df6c0f33373f78/chrome/browser/ui/views/frame/browser_non_client_frame_view_mac.mm
[modify] https://crrev.com/fa2a40240c78edaf9dacbc7ff8df6c0f33373f78/chrome/browser/ui/views/frame/browser_view_layout.cc

Update:

Rechecked the above issue on latest Dev version 69.0.3497.23 on Mac (10.12.6, 10.13.1, 10.13.6, 10.14) and the original issue is found Fixed. Hence, adding the respective labels.

Please refer the attached screen-cast.

Thank You..!!

Deleted: Fixed Video.mov 2.1 MB

	Fixed Video.mov 2.1 MB View Download

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

commit 42e84a429fd09f1076806137cce197a7105c7c87
Author: Sidney San Martín <sdy@chromium.org>
Date: Wed Sep 26 00:31:47 2018

[Mac] Delete ViewsCompositorSuperview. Shouldn't change behavior.

Bug:  865901 
Change-Id: I02010ee8fec71011353f1b0be23e54055af0adf4
Reviewed-on: https://chromium-review.googlesource.com/1236675
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594160}
[modify] https://crrev.com/42e84a429fd09f1076806137cce197a7105c7c87/ui/views/cocoa/bridged_native_widget.h
[modify] https://crrev.com/42e84a429fd09f1076806137cce197a7105c7c87/ui/views/cocoa/bridged_native_widget.mm
[modify] https://crrev.com/42e84a429fd09f1076806137cce197a7105c7c87/ui/views/controls/menu/menu_runner_cocoa_unittest.mm
[modify] https://crrev.com/42e84a429fd09f1076806137cce197a7105c7c87/ui/views/widget/native_widget_mac_unittest.mm

Note: I tagged the above CL with the wrong bug. The relevant one is issue 868398.

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

commit 8ab144369afb2e7090803bdcec097d216fec4948
Author: Sidney San Martín <sdy@chromium.org>
Date: Wed Nov 14 22:07:16 2018

[Mac] Fix hidden NSViews by bringing back a dedicated compositor view.

Until macOS 10.13, the relative ordering of a view's subviews' layers and
unassociated sublayers is undefined, so view layers can end up hidden behind
the compositor layer. See:

  https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKit/index.html#10_13Layer-backed%20Views

This change re-adds a dedicated compositor view, but with less plumbing than
what was removed in r594160.

Bug:  865901 ,  899499 
Change-Id: Ibbec83da2e8785e06522008dfc2d9eab7ca43bf9
Reviewed-on: https://chromium-review.googlesource.com/c/1334290
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608139}
[modify] https://crrev.com/8ab144369afb2e7090803bdcec097d216fec4948/ui/views/widget/native_widget_mac_unittest.mm
[modify] https://crrev.com/8ab144369afb2e7090803bdcec097d216fec4948/ui/views_bridge_mac/bridged_native_widget_impl.mm

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

commit 549a8efa2657a419495c00d285c974b2e27adca8
Author: Sidney San Martín <sdy@chromium.org>
Date: Thu Nov 15 21:46:37 2018

[Mac] Fix hidden NSViews by bringing back a dedicated compositor view.

Until macOS 10.13, the relative ordering of a view's subviews' layers and
unassociated sublayers is undefined, so view layers can end up hidden behind
the compositor layer. See:

  https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKit/index.html#10_13Layer-backed%20Views

This change re-adds a dedicated compositor view, but with less plumbing than
what was removed in r594160.

(cherry picked from commit 8ab144369afb2e7090803bdcec097d216fec4948)

Bug:  865901 ,  899499 
Change-Id: Ibbec83da2e8785e06522008dfc2d9eab7ca43bf9
Reviewed-on: https://chromium-review.googlesource.com/c/1334290
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#608139}
Reviewed-on: https://chromium-review.googlesource.com/c/1338460
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#705}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/549a8efa2657a419495c00d285c974b2e27adca8/ui/views/widget/native_widget_mac_unittest.mm
[modify] https://crrev.com/549a8efa2657a419495c00d285c974b2e27adca8/ui/views_bridge_mac/bridged_native_widget_impl.mm

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

Commit: 549a8efa2657a419495c00d285c974b2e27adca8
Author: sdy@chromium.org
Commiter: sdy@chromium.org
Date: 2018-11-15 21:46:37 +0000 UTC

[Mac] Fix hidden NSViews by bringing back a dedicated compositor view.

Until macOS 10.13, the relative ordering of a view's subviews' layers and
unassociated sublayers is undefined, so view layers can end up hidden behind
the compositor layer. See:

  https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKit/index.html#10_13Layer-backed%20Views

This change re-adds a dedicated compositor view, but with less plumbing than
what was removed in r594160.

(cherry picked from commit 8ab144369afb2e7090803bdcec097d216fec4948)

Bug:  865901 ,  899499 
Change-Id: Ibbec83da2e8785e06522008dfc2d9eab7ca43bf9
Reviewed-on: https://chromium-review.googlesource.com/c/1334290
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#608139}
Reviewed-on: https://chromium-review.googlesource.com/c/1338460
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#705}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}