The latest Nightly version of Firefox for Android has a really nice "scroll the address bar off the screen" feature which is nicer to use than the current feature in the Gaia Browser. I'd like to explore taking a similar approach in Gaia.

CC'ing myself and Chris Lord (who wrote that feature). Note that Chris is currently working on a rather large change to how that works, in terms of the coordinate systems things are using. It would be good if Gaia did something similar so that when we unify the Fennec and B2G pan zoom controllers, they deal with this the same way as well.

A break down of how this will work after the refactor (which is tracked in bug 858969): - Fennec has what we call viewport metrics - this is an immutable structure that holds all the information related to the size and position of the page and the viewport. - In these metrics, we hold margins. These margins can offset rendering (top-left for ltr pages, top-right for rtl) - During async composition, when the compositor asks for our metrics, we give it this render offset and we also calculate what we call 'fixed layer margins', which are offsets that are only applied to layers that have IsFixed (i.e. they represent fixed-position content) - During page-rendering, we let Gecko know about these same 'fixed layer margins' by calling nsIDOMWindowUtils.setContentDocumentFixedPositionMargins - these means that these margins will be reflected in layout, which means that input works correctly on offset elements, and can fix some transient rendering issues - During display-list building, fixed layers are annotated by the content document fixed-position margins that were applied to them while rendering - The compositor translates all rendering by the offset, and selectively translates fixed layers by the difference between the given fixed layer margins and the fixed-position margins that were noted on the layer That describes how the mechanism works, and ought to give some idea of what would be needed in b2g to support that part... In terms of front-end code: - The front-end sets a series of maximum margin values on the object that represents the browser, Java-side (this is the GeckoLayerClient, which I will refer to as GLC from here on). These maximum margin values reflect the pixel size of obscuring chrome (i.e. the toolbar) - The GLC has ownership of the page metrics, and anything that needs to modify them has to go through it. - When scrolling, the GLC has the responsibility of updating the margins on the metrics. For any scroll event, it will alter the margins before scrolling the viewport, up to the maximum margin, and down to zero. Any left-over value is then applied to the viewport origin, as normal (see GLC.scrollBy). - The front-end is responsible for correlating the margins with actual chrome. So in fennec's case, for example, the chrome is responsible for telling GLC to show/hide margins when scrolling stops, as this depends on UI details - When the compositor asks for our viewport details, we calculate what 'fixed margins' we need from our 'ui margins' (so generally, if there's a margin at the top, we add a fixed margin at the bottom) - In our CSS viewport handling, the first measurement of the page we do with the maximum margins taken away from the browser size. This lets us know if the page could fit in the screen with the margins visible - if it's larger than the screen, we set the browser size to the full screen size including margins. - When the page changes size and it equals the screen size, we go through our CSS viewport handling code again and re-measure. There are some guards against reentrancy and loops in this code (see browser.js sendViewportUpdate and updateViewportSize) - this step allows pages that size themselves to the screen to remain unscrollable.

I didn't read everything, but I'm just commenting to note that when I scroll down a bit and stop, just enough to make the address bar hide, the address bar will keep reappearing and hiding. The source of this problem is due to the position of the page changing with the address bar coupled with the fact that the page can appear behind the address bar (and not necessarily always at the top). Pick either one or another, or have it so that the range of where the address bar would reappear is far enough to not intersect with where it disappears.

(In reply to Daniel Nunes from comment #3) > I didn't read everything, but I'm just commenting to note that when I scroll > down a bit and stop, just enough to make the address bar hide, the address > bar will keep reappearing and hiding. The source of this problem is due to > the position of the page changing with the address bar coupled with the fact > that the page can appear behind the address bar (and not necessarily always > at the top). Pick either one or another, or have it so that the range of > where the address bar would reappear is far enough to not intersect with > where it disappears. I think you might be looking for bug 833795 - I think people are well aware of the issues though, don't worry :)

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/53548647

We discussed this and this is the current plan to get this done (devised by roc): - The top-level container will be a scrollable container that contains the browser element and the toolbar - it will be sized to the size of the screen + the toolbar so that the toolbar can be scrolled off (detail to figure out here: We don't always want the toolbar to be scrollable - how do we turn this off/on?) - Clipping will be disabled on the iframe so that the displayport area will be visible during async panning - this requires either some way of inferring we want this situation or to be exposed in browser API - When panning downwards, the outside container needs to pan before the inner browser element pans. I think we should infer that a browser iframe always wants this behaviour (outer container scrolls before inner) - if you like, you could frame this as being necessary to stop inner content from DoS'ing outer. - When the toolbar is made fully hidden or visible and panning continues, it needs to contine inside the browser element. This requires APZC to be able to hand off panning to another APZC. This will get us quite fennec-like behaviour - it won't be identical and there are other bits to work out, but this is most of the way.

Note, bug 886646 (implementing position:sticky) may possibly have some bearing on how we decide to implement this. Probably not, but worth a mention.

I don't think position:sticky helps us here. To use it. we'd have to have a scrollable element which is the height of the URL bar plus the subdocument's scrollable height, which isn't going to work (especially given the subdocument's in a different process).

This is a first attempt at the Gaia changes required to implement the plan cwiiis outlined in comment 7. This patch: 1. Removes the old code for transitioning the address bar on and off the screen. 2. Makes the div that contains the address bar and the browser iframe scrollable, and sizes the iframe to take up the full height of that div, so that when it's fully visible the address bar is scrolled off the top of the screen. I took care not to introduce the same effect for the start, awesome, and crash screens. Of course, this does not give us the desired behaviour yet. That will require platform changes, too, which will be my next step. For now, I'd just like to get feedback on whether I've implemented the Gaia changes correctly. I am new to CSS, and I would appreciate any tips or feedback.

Comment on attachment 791488 [details] [diff] [review] Part 1 - Gaia changes Review of attachment 791488 [details] [diff] [review]: ----------------------------------------------------------------- I'd obviously like to review this once the platform changes are ready so I can properly understand how it works, but this code looks great. I particularly like how much code we get to delete!

Comment on attachment 791488 [details] [diff] [review] Part 1 - Gaia changes Moving patch to bug 835152, it's more appropriate there.

Untaking as this has a lot of dependencies. I will take each dependency as I get to them.

So. This isn't happening any more.