Peter, what do you think? Seems to be WAI.

Mike, do you know if Chrome for Android works in the same way?

Android M57 and iOS M58 both work similarly.

mehmet@ note that release 49 is more than one year old. I didn't test against this version, but it may work somewhat differently than in more recent releases. (Although the bar still does appear when you scroll up.)

To help scope the problem, are you on an iPhone 5 screen size device where screen real estate is more critical?

michaeldo@: Yes, I am using an iPhone 5 SE. Thanks. 

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

Still valid.

Theresa, who would be the right person on Android team to comment on this? 

+nickrad@ +tedchoc@

Adding back UI>Browser>FullScreen, because on iOS we consider this feature as FullScreen.

On Android if you scroll the toolbar off and don't lift your finger, we don't bring the toolbar back in until you scroll the full distance back to when it was initially hidden.

Basically on a long page, start with your thumb on the bottom of the screen and scroll up.  When your thumb reaches the top, scroll back down and you'll see it requires you to scroll back to where you started before the omnibox comes back.

If anything, we could add some slight delay to allow you to lift your finger briefly and keep it in this mode, but I don't know if that would break other things.

mehmet@, what do you think about behavior from comment #11? Would you consider this bug as fixed if iOS do the same?

We have the same behavior as described in Comment 11; for a single pan gesture, the toolbar is locked to its initial content offset in the page, and will only be shown again if the user scrolls all the way back to where that content offset is visible.

I think that what this bug is requesting is for a secondary pan that occurs after the page has been scrolled and the toolbars completely hidden.  I had talked with Peter a bit about this, and it seems like something we'd like to do.  A couple options for implementing this would be:

1. Add a constant "padding" offset.  This would mean that once the page is in fullscreen, we'd need to scroll X points before having the toolbar start to be shown again.  This would be a good first pass implementation, although it'd require some fine tuning of the right value of X to differentiate between small scrolls to read more content vs. faster scrolls intended to jump further in the page.  This would also be the easiest to implement.

2. Gate the toolbar reveal based on the velocity of the WKScrollView's pan gesture.  This would mean that slow scrolling that occurs when reading a long article won't bring the toolbars back into view, but faster scrolling indicative of swiping to the top/bottom of the page will show the toolbar.

Thanks! If we choose to change the existing behavior, then it would be great to keep the consistency across iOS and Android.

Thanks @all for your listening and implementing of this request :-)