Explainer for URL bar hiding changes

96 views
Skip to first unread message

bo...@chromium.org

unread,
Dec 2, 2015, 5:35:53 PM12/2/15
to input-dev
Hello input-dev,

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:

https://github.com/bokand/URLBarSizing

Kartikaya Gupta

unread,
Dec 2, 2015, 6:33:37 PM12/2/15
to David Bokan, input-dev
FYI Firefox for Android's behaviour with respect to the URL bar
changed in bug 1180295 (which is in Firefox 43, currently in Beta, due
to be released in a couple of weeks). It is now more in line with how
Chrome behaves (or used to prior to your changes :p). Specifically:

- Content area (ICB) gets resized when the URL bar is shown/hidden
- Resizing of the content area (and resize event dispatch) happens
when finger is lifted and the url bar is animated to fully
shown/hidden.
- position:fixed items will also get recomputed at the resize,
although their positioning is also updated in the compositor while the
user's finger is down
- I'm not sure about vw/vh units but I'm assuming they are based on
the same viewport size that everything else uses so they will also get
resized at the same time
- window.innerWidth and innerHeight should also get updated based on
URL bar visibility, assuming not overridden by a meta-viewport tag (I
don't have the details on this offhand but I can check if you need me
to).

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.

Cheers,
kats
> --
> You received this message because you are subscribed to the Google Groups "input-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.

bo...@chromium.org

unread,
Dec 2, 2015, 9:16:40 PM12/2/15
to input-dev, bo...@chromium.org
Hi Kats,

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

Kartikaya Gupta

unread,
Dec 3, 2015, 5:24:54 PM12/3/15
to David Bokan, input-dev
If I'm understanding you correctly, then the only change we need to do
in Firefox to be compatible is to keep the ICB (i.e.
document.documentElement.clientHeight) constant, sized to the height
with URL bar showing. All the rest should fall out of that. I'm not
100% sure I've wrapped my head around this yet though (at least partly
because I'm not familiar with some of the relevant aspects of layout)
so I'll give it some more thought. If it turns out that's all there is
to it then it seems reasonable enough.

Rick Byers

unread,
Dec 3, 2015, 5:28:23 PM12/3/15
to David Bokan, input-dev
Thanks for chiming in Kats!

This isn't the first time we've had one browser shipping changes to match our behavior around the same time we're changing our behavior to better match other browsers ;-).  This is a good sign that we should be trying to capture the details in some spec somewhere (and having the debates there).  Dave, I don't want to block your work but once you've got the changes you want in 'experimental' state in Chrome, perhaps you want to start a standards discussion somewhere?  Maybe CSSOM View (so www-style) would be the best place to start?  Or we could just take this to the WICG.

From a practical perspective, if we (blink/gecko) can agree that Safari's behavior is reasonable then it's most practical to just match them and document what that is somewhere.  But if we have a compelling reason to do something differently, then it may be worth trying to convince them to change.

Rick

On Wed, Dec 2, 2015 at 9:16 PM, <bo...@chromium.org> wrote:

bo...@chromium.org

unread,
Dec 4, 2015, 8:44:40 AM12/4/15
to input-dev, bo...@chromium.org
On Thursday, December 3, 2015 at 5:24:54 PM UTC-5, Kartikaya Gupta wrote:
> If I'm understanding you correctly, then the only change we need to do
> in Firefox to be compatible is to keep the ICB (i.e.
> document.documentElement.clientHeight) constant, sized to the height
> with URL bar showing. All the rest should fall out of that. I'm not
> 100% sure I've wrapped my head around this yet though (at least partly
> because I'm not familiar with some of the relevant aspects of layout)
> so I'll give it some more thought. If it turns out that's all there is
> to it then it seems reasonable enough.

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.

bo...@chromium.org

unread,
Dec 4, 2015, 8:49:02 AM12/4/15
to input-dev, bo...@chromium.org, kgu...@mozilla.com
On Thursday, December 3, 2015 at 5:28:23 PM UTC-5, Rick Byers wrote:
> Thanks for chiming in Kats!
>
> This isn't the first time we've had one browser shipping changes to match our behavior around the same time we're changing our behavior to better match other browsers ;-).  This is a good sign that we should be trying to capture the details in some spec somewhere (and having the debates there).  Dave, I don't want to block your work but once you've got the changes you want in 'experimental' state in Chrome, perhaps you want to start a standards discussion somewhere?  Maybe CSSOM View (so www-style) would be the best place to start?  Or we could just take this to the WICG.
>
Agreed, I'll start looking into this shortly. Kats, are you the best contact person on the Mozilla side for this?

Kartikaya Gupta

unread,
Dec 4, 2015, 9:37:06 AM12/4/15
to David Bokan, input-dev
On Fri, Dec 4, 2015 at 8:49 AM, <bo...@chromium.org> wrote:
>>
> Agreed, I'll start looking into this shortly. Kats, are you the best contact person on the Mozilla side for this?

Sure, you can use me as the contact person on the Mozilla side.

I have some more questions though: in addition to the URL bar
showing/hiding, you can also have a virtual keyboard showing/hiding.
Is that going to be subject to the same behaviour (i.e. not resizing
the ICB?). Because then the bit about sizing the ICB to the "smallest
possible viewable area" should be defined more precisely. I also want
to make sure that we settle on a solution that is robust enough to
deal with the more general problem and not specific to top controls.
In the future we might have other overlay control panels of various
kinds and it would be great to deal with them in a consistent way.

kats

bo...@chromium.org

unread,
Dec 4, 2015, 3:19:39 PM12/4/15
to input-dev, bo...@chromium.org

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.

Reply all
Reply to author
Forward
0 new messages