+security>ux 

That sounds right to me. Clank also has toolbar-re-showing logic, IIRC. We'd want the origin information to stick around long enough to be readable - but I don't feel strongly about the specifics beyond that. Pete/Sarah, I defer to you for timing. 

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

commit 7f53ca50f95788ed49dae6134dd92a69c2975b1e
Author: spqchan <spqchan@chromium.org>
Date: Wed Jun 29 22:26:52 2016

[Mac] Reveal Fullscreen Toolbar for Tab Strip Changes

Reveal the fullscreen toolbar for a short duration when the tabstrip has
changed. This feature is hidden behind the
enable-fullscreen-toolbar-reveal flag.

BUG= 591776 
Tests= Run
BrowserWindowControllerTest.FullscreenToolbarExposedForTabstripChanges

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

[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/app/generated_resources.grd
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/browser/about_flags.cc
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/browser/ui/cocoa/browser_window_controller.h
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/browser/ui/cocoa/browser_window_controller.mm
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/browser/ui/cocoa/browser_window_controller_browsertest.mm
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/browser/ui/cocoa/presentation_mode_controller.h
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/browser/ui/cocoa/presentation_mode_controller.mm
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/browser/ui/cocoa/tabs/tab_strip_controller.h
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/browser/ui/cocoa/tabs/tab_strip_controller.mm
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/browser/ui/cocoa/tabs/tab_strip_controller_unittest.mm
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/browser/ui/cocoa/toolbar/toolbar_controller.h
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/browser/ui/cocoa/toolbar/toolbar_controller.mm
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/common/chrome_switches.cc
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/chrome/common/chrome_switches.h
[modify] https://crrev.com/7f53ca50f95788ed49dae6134dd92a69c2975b1e/tools/metrics/histograms/histograms.xml

This is now implemented behind the enable-fullscreen-toolbar-reveal flag.
The fullscreen toolbar will drop down for tabstrip changes. There are still a couple of things I want to polish.

Looking good spqchan@, but it feels a little fast to me (when testing on the W3Schools example Mike outlines above on a fast network).

Could we try making the toolbar+tabstrip visible until the page has fully loaded and then hide it again after a 2sec timeout?

I have a couple of ideas on how to implement that, but what if the page hangs?
I think it's better to just slow down the animation and timeout

Good point. Maybe try somewhere between 3–4 seconds for the timeout. As for the animation speed, I would suggest using the same animate-in/out curves/timing/etc. used to show/hide the toolbar in Full Screen when you move your mouse to and from the screens top edge.

Sounds good, I'll increase the timeout to 3 seconds. Note, the animation is exactly the same as the normal show/hide animation

Here's what it looks like when I increase the timeout. IMO 3 seconds is too long, but 2 seconds seems pretty good.

I'm going to try to make the dropdown animation less janky

Deleted: 2 seconds.mov 10.0 MB

2 seconds.mov 10.0 MB Download

Deleted: 3 seconds.mov 9.5 MB

3 seconds.mov 9.5 MB Download

I made changes to the animation so that it's less janky. 
Here's what it now looks like. WDYT?

Deleted: slowed down animation.mov 4.0 MB

slowed down animation.mov 4.0 MB Download

The slowed down animation looks much better! Also, the 2sec timeout looks good to me from the video.

One thing I noticed is that by the time the toolbar animates in, the new tab's animation has already run, and the only thing left to denote it as the new tab is the loading indicator. What do you think about ensuring the new tab animation in the tab strip doesn't start until after the toolbar is visible – or at least delay slightly – so that you can see which tab is being opened? Just a thought...

Awesome. That's a good point, I'll give that a try

Here it is:

Deleted: revealBeforeInsert.mov 9.7 MB

revealBeforeInsert.mov 9.7 MB Download

Thanks! It still feels too fast though. I made a quick prototype to test, and I think it would be a better to delay the new tab animation by about 300ms after the toolbar finishes animating in. Check out the attached video and let me know if you agree. Thanks for bearing with me :)

(the current animation sequence is OK when you are expecting the toolbar animation and are looking in that area, but in the normal flow your eyes will be focused on where you are clicking and the toolbar animation will then bring your gaze up with a slight delay)

Deleted: fullscreen-new_tab_animation.mov 756 KB

fullscreen-new_tab_animation.mov 756 KB Download

No prob! I made changes according to your prototype. I find that 300ms looks more smooth when we're inserting a new tab, but it's too slow when we're switching tabs.

I think we should make it at most 150ms for switching tabs, and around 300 ms for inserting a new tab. I added videos of 150 and 300ms delays (please ignore that the incorrect color for the tab before we switch into it, it's something I'm trying to solve)

Deleted: 150ms.mov 10.4 MB

150ms.mov 10.4 MB Download

Deleted: 300ms.mov 12.8 MB

300ms.mov 12.8 MB Download

 Issue 432177  has been merged into this issue.

@pschaffner, ping :)?

Pete's home sick today and is about to head OOO for a few weeks.
cleer@ will be a good point of contact on the UX side while he's out. 

> I think we should make it at most 150ms for switching tabs, and around 300 ms for inserting a new tab.

Perfect. the 150ms movie LGTM! Thanks, spqchan@.

Awesome, thanks

If you fullscreen a window that has several tabs and use Cmd-Option Left/Right to switch between them, the timer to hide the top chrome should reset after each tab change. Right now if I cycle through the tabs in a fullscreen window the toolbar will sometimes disappear right after I switch to a different tab.

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

commit d8fafb98e8e3a3829e6671432e2e5782242d9121
Author: spqchan <spqchan@chromium.org>
Date: Fri Feb 03 17:06:20 2017

[Mac] Fix for fullscreen tabstrip animation

Fix for an issue where the tabstrip animates out when you're still
cycling between tabs.

BUG= 591776 

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

[modify] https://crrev.com/d8fafb98e8e3a3829e6671432e2e5782242d9121/chrome/browser/ui/cocoa/fullscreen/fullscreen_toolbar_animation_controller.mm

Sorry for the late updates, my work was shifted on refactoring fullscreen code. Anyway, I’ve been working on implementing the animation change at #14, but erikchen@ pointed out that there’s an issue where the user spams the “new tab” button. If we wait for the toolbar to dropdown before we insert a  new tab, in this situation, this might actually make the browser look sluggish. I’ll keep the slow down animation but I don’t think we should keep the tab delay for this.

Also, I just landed a CL that fixed the  issue #22 

Hello spqchan@,

I noticed a strange behavior in latest Canary on Mac OS 10.11.6.

When I select "Hide always Toolbar in Fullscreen Mode", then the Tabstrip never appears (or appears immediately) when I open a new tab.

Please see the enclosed screencast.

Is this a known regression?

Thanks.
Mehmet

Deleted: bug_fullscreen.mov 875 KB

bug_fullscreen.mov 875 KB Download

No, please open a new bug and assign it to me

Done: Filed  issue 689115 . Thanks!

Are there any blockers to making chrome://flags/#enable-fullscreen-toolbar-reveal on by default?

( It's being implemented for ChromeOS in  Issue 542851  -> CL: https://chromium-review.googlesource.com/c/575843/3 )

The launch is being tracked in Issue 695210. I will see about moving it along.

spqchan@ - please set up a 50/50 experiment for this feature on Canary and Dev.

Sounds good

This was fixed a while ago