cc me too!

+hwi@, who is doing some top-of-screen explorations for other prompts.

Just want to clarify:

1) This overlay issue is true for all banners/info bars on screens with no scroll? I bet this happens more with a location request rather than a banner, which has high standards for reveal. It could almost just mean a minimized treatment for banners on pages that don't scroll.
2) There is no way we can dismiss info bars for this particular case? (The site would have to show the QR code in a dialog for Chrome to know? Any other way?)

1) Yes, that is true. I'm sure there are many cases where permissions cover content. on my personal site I've seen the 'save password' infobar cover the FAB, making first run of the site very confusing.

2) There's nothing we can automatically do in this case as Chrome isn't aware of what content it's hiding.

The real solution is for Chrome to inform sites that they have less space than they thought. Moving the infobar to the top is an easy way, otherwise we could fire resize events into the page as the infobar comes in. I presume we didn't do this due to performance, although if that were the case it may be worth revisiting.

Dan/Ted - do you guys have thoughts about how we could solve this? Is there some feasible world in which we fire resize events (or some other solution) for infobars?

I'm strongly against special-casing the app banner to be at the top of the page and keeping the other infobars at the bottom:

1) We'd need to break the app banner back out of the infobar system.  It started out separately and required a ton of work to shoehorn it into there in the first place.

2) The page would be squished from the top and the bottom if an app banner and an infobar appeared.  If you made it so that only one would appear at a time, you'd still have random bars popping up out of the top and the bottom of the screen.

3) Clank received several loud internal complaints about the screen being covered entirely by infobars, so we had to implement stacking.  Breaking it out will mean that it won't stack with anything.

That said: infobars overlapped the page because it used to be (may still be) expensive to resize the content as something scrolls into and off the screen.  Adding aelias@ as a triage point for commenting on that end.

Yeah, obviously anything we do here should should be general to all infobars.  There are basically 3 viewporting options, all of which we're shipping already for certain UI element.

1) Today's infobar behavior -- overlay the page without interacting with it in any way.  Infobar must be dismissed to observe/tap what's below it.

2) Onscreen keyboard behavior on ChromeOS (and soon for Android when ymalik@ finishes it -- you can try it out with the flag --enable-osk-overscroll): overlay the page in a way that's imperceptible to Blink, but allows scrolling the CC "visual viewport" so that the user can look underneath the infobar anyway.

3) URL-bar behavior: actually change the Blink-visible viewport.  This pushes up bottom-fixed-position elements, and for short pages like the airberlin screenshot, it will make the page bounce around as it relayouts.


Behavior 2) is similar but strictly better than 1) so I propose we adopt it for infobars.  It's unclear that behavior 3 is better -- it's a pain to deal with, and my inclination is to continue to apply that one only for the URL-bar.


> 5) ***Are there other options we could explore??***

IMO the root cause is that we're not letting webdevs control the timing of the appearance of infobars.  I'd suggest exposing an API providing limited control over them so that they don't appear at inopportune times, but rather at natural phases of the user interactions (e.g. on a success! page after the task is complete).

+1 to using behavior #2 where we shrink the "visual viewport" but not the "layout viewport", allowing scrolling but not resizing the page. In general, causing a relayout of the page can cause a negative UX with little benefit in most cases, as long as the user can scroll the desired content into view. This is particularly problematic as the info bars can be varying sizes and so difficult to test layouts for all scenarios.

In addition, we're actively working on adding APIs so that a motivated dev could fix certain important elements to the "visual viewport", which would get shrunken with the info bar in this case. In the example above, the dev might want to keep the QR code fully visible but the rest of the page wouldn't need to respond. They could either use position: device-fixed (issue 542770) which is like position: fixed but relative to the visual viewport and explicitly for UI like the on screen keyboard, infobars and pinch-zoom. Another overlapping proposal is the visual viewport API ( issue 635031 ) where the page gets events and explicit information about the visual viewport size and location.

behavior #2 will ensure that the user can scroll to see the content behind the infobar. 

In terms of shipping "enable-osk-overscroll", it's mainly blocked on shipping the visual viewport API, and I'll prioritize it after its shipped (m55).

position:device-fixed will need to be implemented and is probably a few milestones away.

Per No. 2 in Comment 7 - This is only on pages that can't scroll yeah? Currently info bars dismiss on scroll and I wouldn't want to lose that. But say the page is short and in the infobar prevents scrolling beyond it, then that makes sense to afford scrolling to see the whole page.

The behavior applies on both scrollable and unscrollable pages. I don't see a reason to treat them differently, if a user scrolls to reveal more content I think that's a signal that they're not interested in the info bar, regardless of whether the page was initially scrollable or not.

I might not fully understand the concept, but definitely would be up for seeing a prototype. Right now I rather the info bar go away completely on scroll than the user be able to scroll the page and the bar stays rooted (I don't think that's being proposed but clarifying just in case.) Dismiss on scroll is fairly useful for current info bars but am open to something else if it feels OK.

I'd like to make sure we can easily support UIs that have navigation controls fixed to the bottom.

For example, consider the PWA https://www.BaBe.news which had to disable the banner because it was overlapping with their primary navigation (screenshot). I've also seen this for sites that use the Material Design FAB in the bottom (screenshot).

I suspect a 'scroll to reveal' approach would result in users not discovering the navigational UI in cases such as that, which worries me.

So far as I can see, only option 3) (URL-bar behavior) would make it easy for users to discover bottom-fixed navigation controls and alleviate the kinds of issues we saw with https://www.BaBe.news

While we're discussing, do we have a sense for how challenging it would be to move infobars over to the 3) viewporting approach?

Deleted: Screen Shot 2016-09-29 at 1.20.04 PM.png 547 KB

	Screen Shot 2016-09-29 at 1.20.04 PM.png 547 KB View Download

Deleted: Screen Shot 2016-09-29 at 1.21.19 PM.png 139 KB

	Screen Shot 2016-09-29 at 1.21.19 PM.png 139 KB View Download

I think an API like position: device-fixed (issue 542770) would resolve your concern, am I right?

I agree we can't overlay bottom-fixed navbars but the URL bar approach means we relayout the page when it comes in/goes away, this will look particularly bad with the scroll-to-dismiss functionality. IMO, our experience with the URL bar has shown this to be problematic for both users and developers;  issue 428132  has many stars and complaints. As a result I'm currently looking change the URL bar to not cause relayout on hiding.

Yeah, I take your point. position:device-fixed would certainly give us more options here, although we would break all existing content, and of course we don't have it yet :)

Huh, Safari on iOS seem to have solved this problem already (they have a bottom bar with the same behaviour as our infobars that doesn't overlap content). I've attached a screen cap. Do we what rough model they're using of screen size for that solution?

I presume we will also have the same problem with Chrome Home and obscuring site's navigational UI would be really bad in that case. Do we already have a plan in place for solving that?

Deleted: fixed.mov 6.6 MB

fixed.mov 6.6 MB Download

Removing myself and adding chowse as your primary Web Platform design contact

Looping back around here -

I'm seeing more and more sites with bottom navigation (just last week Pinterest announced a PWA and they have this issue).

I have a strong preference for us finding some solution to this that doesn't require developers update their sites to avoid them being broken, i.e. something that doesn't depend on position:device-fixed.

I see Safari have UI that shows and hides from the bottom of the screen and has the behavior I think makes sense (video attached in comment 15). Do we know how that is implemented (in terms of which viewport it is resizing etc?) since if we can work that out, I'd suggest we implement the same behavior for our own infobars.

It looks to me (or at least, here's how I would do it) that it works very much like the URL bar. Since my comment #14 we've shipped the inert URL bar ( issue 428132 ). Now, showing the URL bar:

-expands the visual viewport,
-expands the layout (fixed) viewport
-does not change the initial containing block (layout height)

The key bit is that we can independently change the fixed viewport and the layout height. So a bottom info bar would shift position:fixed bottom Elements up but would otherwise not affect page layout. (See https://github.com/bokand/bokand.github.io/blob/master/web_viewports_explainer.md for a more detailed explanation of how all this works).

@#18, we already do that hiding for the Chrome Home experiment.  We support controls on the bottom that affect the layout of the page.

With that said, there are experiments with modal permission prompt dialogs and other messaging UI work that makes me not want to rush in to prioritize something that might not be highly used in a couple releases.

Thanks Ted - very interesting to hear we already do this for Chrome Home, that bodes well.

I think it's safe to assume that we'll be stuck with showing a huge amount of infobars at the bottom of the screen for a while yet so I think it's probably worth looking into this.

In terms of infobars, ~85% are non-permissions so the modal permission prompt won't make a huge impact on this (source: https://docs.google.com/presentation/d/1uP1g3lh2P_RC4fjUNuqfbBZYDCd7QHKH44H0I7sxl5Y/edit?ouid=115808220157165952412#slide=id.gd1d645600_9_37)

Also from what I understand about the Messages UI, even in best case we seem at least a year away, assuming the project succeeds at all (which I really hope it does of course!).

In terms of quantity of investment, do we have a sense for how much work it would be to bring the kind of viewport behavior we have with Chrome Home to the infobars? If it's not too large I'm inclined to say it's probably worth it.