As mentioned before, I'm planning to change how the URL bar interacts with the web page. As part of shipping and communicating this more broadly, I've created a GitHub repo with an explainer doc, demo page, and custom Chrome APK showing the differences. This is mostly a cleaned up version of the doc I shared a few weeks back (https://docs.google.com/a/chromium.org/document/d/1kyOHTOJ_qcapdaxChds_hSBG3nSpawllEQoHvtMEcvA/edit?usp=sharing) but feel free to take a look if you're so inclined:
Thanks for the heads up. On our end, we've had plenty of complaints about vh units in particular not interacting well with top controls (http://crbug.com/428132 - has 44 stars). As they are now, they're basically an anti-feature since things will jump around every time the user scrolls in a new direction. Similarly with the ICB, I've personally noticed some pages can be very frustrating to use due to relayout from top controls. For example: https://loren.exposure.co/spring-in-zion, flinging down on that page causes a relayout when the fling finishes, disorienting the user and losing their place in the document.
> Note that we had a lot of people complaining about the old behaviour
> where we didn't provide web content with any mechanism of knowing the
> actual user-visible space consistently. I'm not sure if that factors
> into your decision or not.
Hmm, I've thought about this and it should be fairly easy to polyfill the old behavior if you have a resize event (Firefox today does not). All you have to do is statically size your documentElement/body in the resize handler. Here's a version of my demo page that "emulates" the old behavior when using the version of the browser with my changes: http://bokand.github.io/demo/oldurlbarsizing.html
I'd be quite sad if we diverged in behavior here as much of the work I'm doing is motivated by improving interoperability.
Thanks,
David
Right, I think that with a resize event and actual visible height in innerHeight the author can at least do a bit of work to get what they want. In the default case where they do nothing, the behavior should be simple and user friendly (no surprising relayouts for users).
Disclaimer: I've played around with this a bit and I'm fairly confident its true but I'm not a layout expert so this will have to be confirmed once we get more webby eyes on this.
I'm grappling with this as well, see http://crbug.com/404315. They are similar in that we don't want to resize and relayout the page due to the OSK. There is one major difference between the two which is that we want to the OSK to overlay position:fixed elements (so that they don't obscure the box you're typing into), whereas top controls should not. The difference here is that the OSK is a transient piece of UI whereas the top controls are persistent.
There are cases where you may want to stick some piece of UI to the keyboard (e.g. a formatting bar). Our hope is that Microsoft's position:device-fixed might be the solution here but I agree we should try to come up with a holistic solution. I've filed an issue (https://github.com/bokand/URLBarSizing/issues/3) on my github to ponder on this more. Feel free to chime in with thoughts.