1064982 - outerHeight should include height of url bar

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: Toolbar, defect, P5)

Description

[olivier.stevens]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140830210550

Steps to reproduce:

I use the window.outerHeight and window.innerHeight


Actual results:

the window.outerHeight is similar to window.innerHeight when the url bar is shown

(window.outerHeihgt=windwo.innerHeight)


Expected results:

the window.outerHeight must equal the window.innerHeight+ url_bar.height

(when url bar shown window.outerHeight = window.innerHeigh+urlBar.heigh
when url bar is hidden  window.outerHeight = window.innerHeigh
)

Comment 1

[Aaron Train [:aaronmt]]

Is this a bug with the dynamic toolbar?

Comment 2

[Kartikaya Gupta (email:[e-mail])]

(In reply to Aaron Train [:aaronmt] from comment #1)
> Is this a bug with the dynamic toolbar?

Not really, it's working as intended as far as I can tell. In the case where the page is scrollable and you have the option set to enable dynamic toolbar, the innerWidth does equal the outerWidth, because the "normal" case is that the toolbar is hidden. We want content authors to use the full screen space when laying out their content in JS.

In the case where the page is not scrollable (because the content is short, for example), then the toolbar will always be on-screen and so that is the "normal" case. In this case, the window.innerHeight is in fact less than the window.outerHeight.

Olivier, is there a specific usecase you have where this behaviour doesn't work for you? Please provide additional details on what you are trying to do; there might be some small tweaks we can do to make it work better.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Closing as invalid for now since there hasn't been a response in two weeks. Feel free to reopen or post additional comments if you disagree.

Comment 4

[olivier.stevens]

The problem of the url bar is that when the page is loaded, the url bar is visible and after the user starts a small scroll the url bar is hidden.

My right need is to detect when the url bar is hidden. 

As there is no JS event doing that, I use on all others platform (chome android, native android browser before 4.0, iphone safari) the outerHeight / innerHeight

If I compare with other browser (chome android, native android browser before 4.0, iphone safari)
to an android firefox with default config on a page with content greatest than the phone height :

    > Page loading or scroll is 0 : the url bar is visible [HERE THE PROBLEM]
           > Firefox:
            > url bar is visible
            > window.outerHeight=window.innerHeight [NO] 
         > OTHERS
           > url bar is visible
           > window.outerHeight=window.innerHeight+urlBarHeight [OK]
       

    > user start to scroll [OK]
         > Firefox:
            > url bar is visible
            > window.outerHeight=window.innerHeight  
         > OTHERS
           > url bar hides or reduces
           > window.outerHeight=window.innerHeight (chrome or native android before 4.0) or window.outerHeight=window.innerHeight+urlBarNewtHeight (iphone safari)

For me, the innerHeight must take on account the urlBar when visible whatever the url bar will disepear

Comment 5

[Kartikaya Gupta (email:[e-mail])]

What are you using this information for? The only thing i can imagine needing this information for is to simulate some sort of fixed-position behavior in your content. In such a case it would be better to just use position: fixed elements. One of the reasons we don't expose this is because we do asynchronous scrolling in Firefox which is smoother but also means JS will not be able to run for every single visual update. If you are updating the position of elements in JS as the user scrolls or as the URL bar hides it will jump/jank because it will run at less than 60fps.

Comment 6

[olivier.stevens]

We have got slider vertical component that is reacting to touch action (web app that behaves like google maps application or the city mapper one)

When slider is at bottom position, we have to resize the map at the good size or it could exist conflict or strange map behavour when user click on the slider and map is behind 
(in additions this permits us to avoid to hide the map legal mentions). 

When slider reaching bottom position, the url bar appears -> here we have to do our computation
I have got your point, for now will use a trick base an the ua

Comment 7

[Kartikaya Gupta (email:[e-mail])]

The innerHeight now changes when the url bar is shown or hidden, but so does the outerHeight. This still needs fixing.

Comment 9

[Karl Dubost💡 :karlcow]

The behavior has changed in Chrome 56. The URL bar being visible or not the viewport height is always computed as if the URL bar was hidden.
https://developers.google.com/web/updates/2016/12/url-bar-resizing

The reason for the change are outlined in the blog post:

There are a few reasons for this change:

> * Usable vh units on mobile. Prior to this, using vh units meant 
> a page would reflow jarringly everytime the user changed scroll 
> direction.
> 
> * Improved user experience. If a page reflows while the user is 
> reading they may lose their relative location in the document. 
> This is frustrating but also incurs additional processor usage 
> and battery drain to relayout and repaint the page.
> 
> * Improved interoperability with Safari on iOS. The new model 
> should match how Safari behaves, making life easier for web 
> developers. The unintuitive choice of making vh units the largest 
> possible viewport but the ICB the smallest possible is to match 
> Safari's behavior.


Adding this to the larger meta bug about parity with Chrome for the viewport.

Comment 10

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 11

[Karl Dubost💡 :karlcow]

This probably relates to Bug 1336342

Comment 12

[Karl Dubost💡 :karlcow]

## Firefox Nightly 65.0a1 2018-11-05 on Android 9 / Pixel 2 device

The URL top bar is visible.
    2.608695652173913: window.devicePixelRatio
    688 px: window.screen.height
    607 px: window.innerHeight
    607 px: window.outerHeight

The URL top bar is not visible after scroll
    688 px: window.screen.height
    664 px: window.innerHeight
    664 px: window.outerHeight


## Chrome Canary 72.0.3602.0 on Android 9 / Pixel 2 device

The URL top bar is visible.
    2.625: window.devicePixelRatio
    732 px: window.screen.height
    604 px: window.innerHeight
    604 px: window.outerHeight

The URL top bar is not visible after scroll
    732 px: window.screen.height
    660 px: window.innerHeight
    660 px: window.outerHeight

Chrome and Firefox seems consistent here (apart of devicePixelRatio value and screen height)

Comment 13

[Hiroyuki Ikezoe (:hiro)]

Great, Karl!  I am closing this as WONTFIX.