Hey sdy@: I did a bisect and it seems that this is caused by your latest change from https://chromium-review.googlesource.com/c/581859/

This is the regression range: https://chromium.googlesource.com/chromium/src/+log/a89b266bed601b1526e49553ad929681c31b2de9..17684e9d8dd252a678cc17989303eaf027cbb61a

Can you please take a look? Thank you in advance!

Assigning to the CL owner.

Hi mehmet@,
I can't reproduce this issue. Could you look at the attached screen recording and let me know if I'm doing something wrong? (I do notice that the toolbar no longer animates out. I can look into it, if that's what you mean.)

Deleted: crbug_749224_no_repro.mp4 3.5 MB

	crbug_749224_no_repro.mp4 3.5 MB View Download

Hi sdy@: What I am exactly mean is, that the Toolbar now hides away, when the cursor is over the Omnibox or the Bookmarksbar. So you have no chance to click into the Omnibox or on a bookmark on the Bookmarksbar, because the Toolbar hides away. Before your change, there was a mouse threshold by 50px, so that the toolbar doesn't hide immediately.

Which OS are you using? I am on macOS 10.12.6.

Please find enclosed two screencasts comparing the behavior:

1.) Title "okay" = build 489347 = before your change

2.) Title "not okay" = build 489362 = after your change

Please let me know, if you need more information.

Thank you very much in advance.

Deleted: okay.mov 2.8 MB

okay.mov 2.8 MB Download

Deleted: not okay.mov 3.6 MB

not okay.mov 3.6 MB Download

Huh. I can't get this to happen. spqchan@, any thoughts?

Deleted: crbug_749224_still_no_repro.mp4 2.9 MB

	crbug_749224_still_no_repro.mp4 2.9 MB View Download

(I'm running 10.12.6 too.)

> Huh. I can't get this to happen.

Please move you mouse cursor over the Omnibox or Bookmarks bar and keep it there without further moving. Then it should happen. (It doesn't happen, when the mouse cursor is moving). 

Like this?

Deleted: crbug_749224_still_still_no_repro.mp4 2.3 MB

	crbug_749224_still_still_no_repro.mp4 2.3 MB View Download

That's really spooky :-(

Please see my screencast. I can repro it.

Deleted: screencast.mov 3.7 MB

screencast.mov 3.7 MB Download

mehmet@ - can you copy/paste your variations into this bug? I want to see if perhaps there's an experiment causing the behavior change.

Hi shrike@, here they are from my latest Canary Build, where I can reproduce it too:

Google Chrome	62.0.3168.0 (Offizieller Build) canary (64-Bit)
Überarbeitung	da2455bea333a5a4bfe61ba1fcfe9e325dc368e1-refs/heads/master@{#489803}
Betriebssystem	Mac OS X
JavaScript	V8 6.2.52
Flash	26.0.0.143 /Users/memo/Library/Application Support/Google/Chrome Canary/PepperFlash/26.0.0.143/PepperFlashPlayer.plugin
User-Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3168.0 Safari/537.36
Befehlszeile	/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary --flag-switches-begin --flag-switches-end
Ausführbarer Pfad	/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary
Profilpfad	/Users/memo/Library/Application Support/Google/Chrome Canary/Default

Varianten	

c04e5123-f23d1dea
16e0dd70-3f4a17df
da89714-4ad60575
c68ab9a3-1f8c5973
b130ecb8-2e32ee7e
6025934e-3f4a17df
7c1bc906-ff96eb58
47e5d3db-3d47f4f4
776de70c-eadfd437
5ca89f9-f23d1dea
6c7c7e88-f23d1dea
ed7ba060-f23d1dea
9e201a2b-d151e2f5
57f575bb-f23d1dea
68812885-3f4a17df
332a4d9b-16564fff
f347910c-b2680319
b791c1b8-f23d1dea
9773d3bd-803f8fc4
99144bc3-4da47e09
9e5c75f1-7c147784
e79c5ffa-f23d1dea
f79cb77b-3d47f4f4
23a898eb-a6a00d44
4ea303a6-2b1a91b5
d92562a9-ca7d8d80
de03e059-1410f10
ad6d27cc-3e870323
f56e0452-f23d1dea
b2f0086-3eaf85df
ef25c1eb-f23d1dea
344833e9-1525b35b
3f273a97-e3ad1896
4bc337ce-402fd06c
1354da85-ef8b0206
494d8760-1410f10
3ac60855-486e2a9c
f296190c-a2200d3b
4442aae2-d7f6b13c
ed1d377-e1cc0f14
75f0f0a0-a5822863
e2b18481-a5822863
e7e71889-e1cc0f14
f5fff3a2-3f4a17df
644b8345-3f4a17df
d1c43657-f23d1dea
11d91db8-f23d1dea
828a5926-ca7d8d80
da4aaa01-f23d1dea

Thank you. Unfortunately I didn't see anything that triggered the problem.

Hi shrike@/sdy@:

Now I know what is happening :-)

It depends on the Dock/Menubar color that you can select in the macOS-Settings.

This means in detail:

1.) Dark Dock & Menubar => Issue is reproducible

2.) Bright Dock and Menubar => Issue is not reproducible

Please find enclosed a screencast.

I hope this helps you to reproduce the issue.

Thanks!

Deleted: screencast.mov 12.6 MB

screencast.mov 12.6 MB Download

I was unable to reproduce this problem but then I updated my machine to 10.12.6. It might have been the system update, or the reboot with dark menu as the setting from the start, but now I can reproduce the bug in Canary.

sdy@ - are you trying on 10.12.5 or 10.12.6? It also seems strange that this could happen given that Chrome has its own tracking rect to determine if the mouse is out of range (i.e. it should not depend on anything macOS is doing with the menu bar).

Your bug is tagged as Release block Stable. 

M62 is branching soon and We will be taking only CRITICAL merges. Please plan accordingly.

mehmet@ Are you still able to reproduce the bug in latest canary?

Yes I am still able to reproduce it with latest Canary.

sdy@: Can you reproduce it with the Dark Menubar/Dock setting? Thanks.

Eek. I *can* reproduce it with that setting. Investigating.

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

commit 5e66209f463b796438636e8eee1d1437c528980f
Author: Sidney San Martín <sdy@chromium.org>
Date: Wed Aug 23 03:06:02 2017

Fix toolbar hiding while the mouse is still over it when the system uses a dark menu bar.

FullscreenToolbarMouseTracker has a method, -updateToolbarFrame:, which
sets trackingAreaFrame_ based on contentView_'s bounds, then calls
-updateTrackingArea. However, -updateTrackingArea is responsible for
setting contentView_, so its value is stale (nil, in this case) when
-updateToolbarFrame: looks at it.

trackingAreaFrame_ only becomes correct if -updateToolbarFrame: is
called a second time. I haven't discovered why, but it looks like we get
extra events from the light menu bar, but not the dark one, which masked
the bug.

Fix the bug by having -updateToolbarFrame: find the content view itself
instead of relying on the contentView_ ivar (which seems to mainly be
used to remember which view currently has a tracking area).

Bug:  749224 
Change-Id: I3c923d09590e3416ebcf8bbb428d1dd44f62fab7
Reviewed-on: https://chromium-review.googlesource.com/627296
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Reviewed-by: Sarah Chan <spqchan@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496574}
[modify] https://crrev.com/5e66209f463b796438636e8eee1d1437c528980f/chrome/browser/ui/cocoa/fullscreen/fullscreen_toolbar_mouse_tracker.mm

Thank you sdy@! I tested it in Chromium Snapshot Build 496591 and the mouse threshold is back again as expected with the Dark Dock/Menu Setting.

But one more thing I noticed, regardless of whether using the dark or bright Menu/Dock Setting:

Steps to reproduce:

1.) Move the mouse-cursor to the top of the screen, so that Menubar and the Toolbar appear.
2.) Move the mouse-cursor so far down, that only the Menubar disappears.
3.) Now move the mouse further down, so that the rest of the Toolbar disappears.

Actual: The rest of the Toolbar disappears very quickly without a smooth animation.

Expected: The rest of the Toolbar should disappear with a smooth animation.

Please find attached 2 screencasts comparing the behavior.

Should I file a separat bug-report for it or do you want to take a look within this bug-report?

Thanks in advance!
Mehmet

Deleted: bug.mov 624 KB

bug.mov 624 KB Download

Deleted: no_bug.mov 691 KB

no_bug.mov 691 KB Download

Cool! File a separate bug for that.

Tested the  issue #62 .0.3196.0 on Mac 10.12.6 as per the observations mentioned in comment #4. Observed tool bar is not disappearing on following the above steps.

Please find the screen cast for the same. Hence adding Verified labels.

Thanks!!

Deleted: Aug 25 2017 3_20 PM.webm 3.5 MB

	Aug 25 2017 3_20 PM.webm 3.5 MB View Download

Tested the issue using #62.0.3196.0.

Thanks!!