Updated repro steps

1. Visit a page (e.g. en.wikipedia.org)
2. Navigate to a new domain (e.g. reddit.com)
3. Scroll down

It seems the cross-domain navigation is important. Opening the browser and loading a page makes the URL bar work. Navigating to links on the same domain doesn't break it.

Bisected this down to:

commit 27caae83cb530daaf49f9a38793e427cdf493a65
Author: Alex Moshchuk <alexmos@chromium.org>
Date:   Mon Sep 11 23:11:18 2017 +0000

    Always create a proxy for cross-process navigations.

Cr-Commit-Position: refs/heads/master@{#501081}

Which explains why the navigation matters. Alex, could you PTAL?

Thanks for filing!  I've reproed this locally and confirmed that it's due to my CL.  Looking.

boliu@: do you know where we determine whether the URL bar should be hidden?  I'm wondering if that has a problematic use of RenderViewHost or an API like RenderViewCreated.

> boliu@: do you know where we determine whether the URL bar should be hidden?  I'm wondering if that has a problematic use of RenderViewHost or an API like RenderViewCreated.

+tedchoc

+mdjones

TabAndroid::UpdateBrowserControlsState
https://cs.chromium.org/chromium/src/chrome/browser/android/tab_android.cc?l=713

Looks to be using RenderViewHost there.

FYI, the Browser sends a message to the renderer that ends up in  WebViewImpl::UpdateBrowserControlsState. That tells the renderer whether the controls can be moved or not. The renderer itself moves the controls and sends the deltas to the browser in a CompositorFrameMetadata. Not sure where it goes from there though or which side (browser/renderer) the issue lies on.

Issue 765715 has been merged into this issue.

#5 and #6: thanks for the pointers.  It appears that TabAndroid::UpdateBrowserControlsState is working correctly - it's always sending ChromeViewMsg_UpdateBrowserControlsState through the active RenderViewHost, and we seem to be calling WebViewImpl::UpdateBrowserControlsState with correct params.  But then, in the problematic case, the LayerTreeHost never ends up calling WebViewImpl::ApplyViewportDeltas, seemingly because  BrowserControlsOffsetManager::ScrollBy isn't calling SetCurrentBrowserControlsShownRatio properly.   I just noticed there's a useful hint at https://crbug.com/765715#c15 as well, so I'll keep digging on that.

OK, found the problem.  We set the browser controls size in multiple places in the renderer, and there's one that's broken, which is Page's browser_controls_.  This is set by WebViewImpl::ResizeWithBrowserControls() when it calls ResizeViewWhileAnchored(), but when this is called for a provisional frame's WebViewImpl, we never get to ResizeWithBrowserControls, due to this early return:

  if (GetPage()->MainFrame() && !GetPage()->MainFrame()->IsLocalFrame()) {
    // Viewport resize for a remote main frame does not require any
    // particular action, but the state needs to reflect the correct size
    // so that it can be used for initalization if the main frame gets
    // swapped to a LocalFrame at a later time.
    size_ = new_size;
    GetPageScaleConstraintsSet().DidChangeInitialContainingBlockSize(size_);
    GetPage()->GetVisualViewport().SetSize(size_);
    return;
  }

I think we should remember the browser controls size change in that block just, like we do it for the regular size and visual viewport.  I've verified that including an 

    GetPage()->GetBrowserControls().SetHeight(top_controls_height,
                                              bottom_controls_height,
                                              browser_controls_shrink_layout);

in that block fixes the problem.  Ken, does that sound about right?  (You added this block in https://codereview.chromium.org/1568383002)

Yes that makes sense. Your change looks like it is uncovering bugs that already existed when a swapped out main frame gets swapped in, but we hadn't noticed because that previously didn't happen very often in practice. I wonder if there is any other important information that we are discarding when there is a remote main frame, although I don't see anything obvious atm.

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

commit a26adbb2e7f97ecb88d7ae9dcf93fe3f8f7d8601
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Mon Oct 02 18:39:00 2017

Preserve browser controls size for remote-to-local main frame navigations.

The browser controls size might be updated in a resize message that
comes in while the main frame is remote.  Previously,
WebViewImpl::ResizeWithBrowserControls early-returned if the main
frame is remote, saving the main widget size, but ignoring the browser
controls size update.  This CL fixes ResizeWithBrowserControls to also
save the new browser controls size, so that it can be used if the
remote main frame swaps back to a local frame.

This affected URL bar hiding on Android, where the resize message was
sent while there was a provisional main frame that hasn't swapped into
the tree yet, causing the renderer to think that the browser controls
had zero height.

Bug:  769321 
Change-Id: I81558bf08483020dc3af7d8a57aa49705704dc05
Reviewed-on: https://chromium-review.googlesource.com/692683
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#505693}
[modify] https://crrev.com/a26adbb2e7f97ecb88d7ae9dcf93fe3f8f7d8601/third_party/WebKit/Source/core/exported/WebFrameTest.cpp
[modify] https://crrev.com/a26adbb2e7f97ecb88d7ae9dcf93fe3f8f7d8601/third_party/WebKit/Source/core/exported/WebViewImpl.cpp

Should be fixed by r505693.

Issue is now not reproducible on latest M63-63.0.3231.0, URL bar is hiding on following steps mentioned in #1. Verified on Nexus 6P/OPR5.170623.009 and Samsung Galaxy Note 5(SM-N920G)/NRD90M