Paul's note: It is currently non-trivial to maximize the visible browser area on mobile devices (i.e. scroll away url bars) or to trigger the native resolution on any device. Additionally, it is almost impossible to create a page that doesn't have scrolling content (device-width doesn't do the trick). Addendum: This has been a pet peeve for a while. I don't believe it's possible for web content to render to the full window at native DPI in Firefox Mobile across all devices. If content doesn't set a fixed width or use meta viewport (blecch!), then we allocate it a width that's usually wider than the native window. In addition, we monkey with the CSS-pixel-to-dev-pixel ratio for various compat issues. That's all fine, but it means that it's not possible for DPI-aware web apps, say a game or PDF reader, to get "native app" quality (pixel perfect rendering). We should fix that. There might be two items here: (i) make it easier to hide hide-able UI, like URL bar (in Firefox Mobile, that's easy but hacky; maybe a standard is needed?); (ii) allow apps to fill the actual window width and render 1:1 with device pixels. I don't have a lot of ideas but I do feel strongly that this should not involve meta viewport at all, and in fact we should start deprecating it. Maybe CSS media queries are the right start for this?

Note: I filed this in Core:General, but this work will touch a lot of different components, up to the frontend.

The W3C CSS Device Adaptation draft standard might be the right way to move forward with this, though at the moment it has some unresolved issues about resolution handling: http://dev.w3.org/csswg/css-device-adapt/ For hiding browser chrome, window.scrollTo is currently the de facto standard for doing this on mobile. Bug 654122 covers cases where this doesn't work in Fennec. For the future, the "right" way might be the fullscreen API (bug 545812) which could also hide OS chrome (not just browser chrome).

(In reply to comment #2) > The W3C CSS Device Adaptation draft standard might be the right way to move > forward with this, though at the moment it has some unresolved issues about > resolution handling: > > http://dev.w3.org/csswg/css-device-adapt/ That looks very promising, thanks. > For hiding browser chrome, window.scrollTo is currently the de facto > standard for doing this on mobile. Bug 654122 covers cases where this > doesn't work in Fennec. Yeah that's the "easy and hacky" thing I referenced above. Certainly not the worst thing on the Web, but that approach assumes a lot about the UI paradigm. > For the future, the "right" way might be the > fullscreen API (bug 545812) which could also hide OS chrome (not just > browser chrome). In general I disagree --- fullscreen is a different beast, with security concerns and associated permissions that need to be granted that something like a PDF reader absolutely doesn't need (normally; might need it for "slideshow mode" or something). I do agree that a lot of the use-cases of full-window drawing for games e.g. would be better satisfied by the fullscreen API.

The plugin we use to handle normalization across devices needs to work through a lot of different hooks to make this work. For once, scrolling away the URL bar via scrollTo isn't as simple as it seems. For once, it's impossible to reliably know the timing when you have to trigger scrollTo to make it work - if you do it on domready or even load, it doesn't scroll way in many browsers (not sure about Firefox mobile). I therefore need to have a interval running that tries to call scrollTo every 10ms after load, and quits as soon as the window.innerHeight has changed adequately. This, however, is not reliable either, as for instance Android browsers report info between keyframes, i.e. "during" the scroll-away of the bar, 720,722,729 and so on. Therefore, on some Android, you have to *know* the expected end height, which is less than ideal. Regarding full screen: We'd love to have a fullscreen API to work against. There's security implications, but it needs to happen. Flash had fullscreen for ages, and it's sorely needed for extensive immersive gameplay.

(In reply to comment #3) > (In reply to comment #2) > > For the future, the "right" way might be the > > fullscreen API (bug 545812) which could also hide OS chrome (not just > > browser chrome). > > In general I disagree --- fullscreen is a different beast, with security > concerns and associated permissions that need to be granted that something > like a PDF reader absolutely doesn't need (normally; might need it for > "slideshow mode" or something). > > I do agree that a lot of the use-cases of full-window drawing for games e.g. > would be better satisfied by the fullscreen API. Can you elaborate on the distinction here? I think if you want to make the browser and OS chrome disappear, the fullscreen API is the right API.

Agreed. The non-fullscreen case is dirt simple: if the browser has hideable UI that's showing after page-load and occluding, say, my PDF, then I want that hideable UI to go away if possible. That's probably true for any "content document". You could argue that that's a UA problem, and I might be inclined to agree :), but the way to make hideable UI go away in fennec and android-browser is by using scrollTo hackery. Also, welcome back.

In Fennec, there are times that the sidebars are open and no amount of scrollTo hackery will hide those, iirc. For the URLBar, scrollTo should work - but we might have a bug filed on that. I know the UX team wanted some control over the UI and when parts are visible and hidden.

(In reply to comment #7) > In Fennec, there are times that the sidebars are open and no amount of > scrollTo hackery will hide those, iirc. That wasn't my experience (bug 638269), but maybe things have changed since then. Agree that that's a bug though, and there are cases when we don't want content to hide open UI.

(In reply to comment #6) > The non-fullscreen case is dirt simple: if the browser has hideable UI > that's showing after page-load and occluding, say, my PDF, then I want that > hideable UI to go away if possible. That's probably true for any "content > document". You could argue that that's a UA problem, and I might be > inclined to agree :), but the way to make hideable UI go away in fennec and > android-browser is by using scrollTo hackery. I still don't understand why the full-screen API is not the perfect API to make that UI go away.

(In reply to comment #9) > (In reply to comment #6) > > The non-fullscreen case is dirt simple: if the browser has hideable UI > > that's showing after page-load and occluding, say, my PDF, then I want that > > hideable UI to go away if possible. That's probably true for any "content > > document". You could argue that that's a UA problem, and I might be > > inclined to agree :), but the way to make hideable UI go away in fennec and > > android-browser is by using scrollTo hackery. > > I still don't understand why the full-screen API is not the perfect API to > make that UI go away. I don't think any of both is exclusive. The full-screen API will most likely trigger alarming looking popups or notification bars that users have to click. That's ok, as it has valid security implications. But a game or website you point your browser to should load immediately. In this case, I want to make sure I can use the maximum visible area on a mobile device. Compare to a fashion store - you could rent the one on the second floor or, a little more expensive, the one on the first floor. The first floor is more attractive as people walking by will be able to see your clothes with basically no effort. To get the full hands-on experience, they still have to push the door and get in.

So you want an API that means "give me the maximum visible area I can get right now without triggering any security UI"? This is a confusing issue because on mobile we don't seem to care security-wise that the URL bar is usually not visible, even though on desktop we try really hard to make sure the URL bar is not spoofable. I'm not sure why we don't care on mobile (other than the obvious that it sucks to have it taking up screen area).

(In reply to comment #11) > So you want an API that means "give me the maximum visible area I can get > right now without triggering any security UI"? Yes. > > This is a confusing issue because on mobile we don't seem to care > security-wise that the URL bar is usually not visible, even though on > desktop we try really hard to make sure the URL bar is not spoofable. I'm > not sure why we don't care on mobile (other than the obvious that it sucks > to have it taking up screen area). Seems people are used to URL bars that scroll away on mobile devices since iOS. Theoretically, somebody could fake the URL bar, have people insert urls in there and do some evil cross-domain scripting scripts or whatever. Haven't heard about it yet though.

OK. It sounds to me like the CSS Device Adaptation proposal fits pretty well then.

(In reply to comment #13) > OK. It sounds to me like the CSS Device Adaptation proposal fits pretty well > then. Gonna have a look. Thanks!

(In reply to comment #11) > This is a confusing issue because on mobile we don't seem to care > security-wise that the URL bar is usually not visible, even though on > desktop we try really hard to make sure the URL bar is not spoofable. I'm > not sure why we don't care on mobile (other than the obvious that it sucks > to have it taking up screen area). (Aside to Mozilla folks: has this design gotten security review? I've been assuming so, but haven't ever asked. Now seems like a good time.)

(In reply to Chris Jones [:cjones] [:warhammer] from comment #15) > (Aside to Mozilla folks: has this design gotten security review? I've been > assuming so, but haven't ever asked. Now seems like a good time.) Bug 605206 was marked wontfx (not sure why. we want to solve this, its just a hard problem to solve). I'm not sure what the difference is between this bug and 677989? The way they read to me, both could be solved by either implementing the CSS Device Adaptation spec (because that gives us an end run around the "iphone" web), or adding a special "-moz-device-resolution" tag to metaviewport.

Refocusing this bug to "full window without unwanted UI". The other bug is about rendering at device-pixel resolution. A special "let me to render to full window and at device resolution" flag doesn't seem too bad to me. I would prefer to have that as part of Device Adaption than pile on apple's hack, but that's just a style issue.

Note wrt bug 844910, this "style" is the default for installed b2g apps, for just this reason. Still relevant for async pan/zoomed code though.