I've added innerHeight to the page to further demonstrate.

On returning to webpage from home the following happens:

Chrome 54 Android:
innerHeight remain set at full screen. Address bar does not autohide. No way to remove address bar or detect that address bar is visible on screen.

Chrome 53 Android:
innerHeight remain set at full screen. Address bar does autohide after 2 seconds. 

Chrome 54 iOS
innerHeight adjusts to new height of page minus addressbar. Address bar does not autohide. Change in innerHeight can be used to detect that address bar is visible on screen.

More information on differing behaviour between Chrome 53 vs 54 on Android and Chrome 54 on Android vs Chrome 54 on iOS

Chrome 54/Android -incorrect behaviour address bar cannot be removed in an intuitive fashion:
* Go to a website:
  http://bbc.co.uk

* Scroll page up and the address bar is removed.
* Press home
* return to web page
* scroll page up and the address bar remains 'locked' on screen. 
* To remove it you have to scroll page down and then scroll up again.

Chrome 53/Android  - address bar is removed:
* Go to a website:
  http://bbc.co.uk

* Scroll page up and the address bar is removed.
* Press home
* return to web page
* scroll page up and the address bar remains 'locked' on screen but autohides after 2 seconds. 


Chrome 54/iOS -correct behaviour address bar can be removed in an intuitive fashion:
* Go to a website:
  http://bbc.co.uk

* Scroll page up and the address bar is removed.
* Press home
* return to web page
* scroll page up and the address bar is removed.

I'm able to reproduce this on a Nexus 5X with Chrome 54.0.2840.68. The issue is that we don't auto-hide the address bar when returning to Chrome. I think we should get this fixed for M55. +aelias@ who might know of some recent changes going on here.

Chao, would you mind taking an initial look? The code that initiates everything should be on the Java side but I'm not sure where that is. It should end up in BrowserControlsOffsetManager::UpdateBrowserControlsState so you can start looking there and work your way up. In the mean time hopefully we can get a bisect.

This issue is come from this patch https://chromium.googlesource.com/chromium/src/+/e5fc57843cf8d21d9bf51e389821657f3f768317 Introduce bottom controls to CC and let it respond to scrolling. ianwen@ Please look at this issue.

Just talked to mdjones@ and we believed that this is not caused by my data plumbing CL. My CL was about data plumbing and did not change the logic in either CC or the browser java code.

1. I suspect siever's change in June about ChromeFullscreenManager is the culprit. https://codereview.chromium.org/2022183005

2. Also I think this is working as intended in some way. When the user returns to Chrome, Chrome should not hide the top control anymore so that the user is aware he is inside of a browser, not a web app.

If this is working as intended shouldn't the innerHeight change to somehow show that the address bar is visible?

This is how Chrome works on iOS
Thanks

Agreed, the URL bar is in "overlay mode" but that should only ever be temporary. If we want to show the url bar on switching activities we should communicate that to the web contents.

Ian, since sievers@ has left the project and you're now the owner of URL-bar hiding, could you work on this?

Also, note that there's no need to make guesses about culprits anymore.  tools/bisect-builds.py now supports Android and it's super fast (no local compiles, pulls builds from https://pantheon.corp.google.com/storage/browser/chrome-test-builds/official-by-commit/Android%20Builder/?prefix=full-build-linux_ ).

I just double check the build. 09cadea5a9a4ebf1a367237093d108db7c2f7da1 is the last one without this issue and e5fc57843cf8d21d9bf51e389821657f3f768317 is the first one has this issue. 

I see. Happy to do further investigation today. ;)

The behavior for top controls has changed in M56. In M56 as long as the user returns to Chrome, the top controls will be visible permanently, and the innerHeight will be correct. https://codereview.chromium.org/2484293003 might accidentally fixed this issue.

The only remaining problem is M55. Still investigating only for M55.

Merge of https://codereview.chromium.org/2513843002/ approved for branch 2883

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

commit 6eea3cdf56c513aa5cc9d08522d1954ba634113b
Author: Ian Wen <ianwen@google.com>
Date: Mon Nov 21 21:02:54 2016

Revert "[Android] Keep top controls visible until an update from a Tab."

This reverts commit 2e2ed096513eb9e7168498fd167dacc2888b338d, because
after commit https://codereview.chromium.org/2106753004, setPositionForTab
is no longer called if there is no change in content offset.

BUG= 660935 
R=tedchoc@chromium.org

Review URL: https://codereview.chromium.org/2513843002 .

Cr-Commit-Position: refs/branch-heads/2883@{#633}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/6eea3cdf56c513aa5cc9d08522d1954ba634113b/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/ChromeFullscreenManager.java

Fixed in M55.

In M55, top controls will have this "overlay" behavior when user returns to Chrome.

In M56, top controls will be permanently visible when Chrome is launched.