923663 - js window.innerHeight includes the address bar area when zoom is greater than minimum value on nexus 10

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Ray Shanley]

Attachment: mozilla-innerHeight-when-zoomed.htm

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36

Steps to reproduce:

1) Open the attached htm file
2) Pinch to zoom in a little
3) Scroll down a bit so the address bar area is not visible. Click on "view innerheight" and note the value.
4) Scroll back up so the address bar area is visible. Click on "view innerheight" and note the value.



Actual results:

Both values are the same e.g. 475


Expected results:

In other browsers like Chrome the value is less when the address bar area is visible e.g. with address bar 477 vs without address bar 542

Comment 1

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

I was discussing this with :tn today, and we decided that the current behaviour seems more correct. The reason is that when the toolbar is visible, it is conceptually "on top" of the page, and so shouldn't affect the "visual viewport" which is actually what is visible under the toolbar. This way of looking at it is more clear if you have the toolbar hidden, and then press the menu button, which brings the toolbar down on top of the content without moving it. In this case we don't want to be changing the innerHeight.

I'm going to WONTFIX this now but if you feel differently please feel free to argue your case. Also if you have a specific use case that you feel would benefit from changing this behaviour I would be interested to know what it is.

Comment 2

[Ray Shanley]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #1)

> The reason is that when the toolbar is
> visible, it is conceptually "on top" of the page, and so shouldn't affect
> the "visual viewport" which is actually what is visible under the toolbar.

I agree with the case you describe where the toolbar is "on top" of the page - I hadn't though of that. However, I think there are 2 cases. I'm pretty certain the other case exists Example1: right after you start the browser. Example2: example I originally described

> if you have a specific use case that you feel would
> benefit from changing this behaviour I would be interested to know what it
> is.

My use case is that I need to know the absolute co-ordinates of all elements on the page and specifically here I need to know the y-offset of the top of the "visual viewport". My formula is as follows:

var offsetTop = window.devicePixelRatio * screen.height - window.innerHeight * zoom;

I'm pretty sure about this because I've seen that my co-ordinates are wrong by that amount in those cases (and also that they are correct in Chrome using the same logic).

Comment 3

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

(In reply to Ray Shanley from comment #2)
> I agree with the case you describe where the toolbar is "on top" of the page
> - I hadn't though of that. However, I think there are 2 cases. I'm pretty
> certain the other case exists Example1: right after you start the browser.
> Example2: example I originally described

But the conceptual model of how the toolbar behaves should be consistent across all of these scenarios. It would be odd if we changed the innerHeight if the user brought the url bar into view via scrolling but not via the menu button.

> My use case is that I need to know the absolute co-ordinates of all elements
> on the page and specifically here I need to know the y-offset of the top of
> the "visual viewport". My formula is as follows:

What is the ultimate goal you are trying to accomplish though? There may be a different way that doesn't require you to know the specific y-offset of the visual viewport. For example you may be able to use getClientBoundingRect and the page scroll offset to figure out the absolute coordinates of all elements, if I understand correctly.

Comment 4

[Ray Shanley]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #3)

> What is the ultimate goal you are trying to accomplish though

We are implementing ui test automation for android web, so we need to know the absolute coordinates of all elements.

Comment 5

[Ray Shanley]

> if you feel differently please feel free to argue your case

I still feel differently ;) Was my argument not convincing?

> For example you may be able to use getClientBoundingRect and the page scroll 
> offset to figure out the absolute coordinates

This does not give the absolute screen co-ordinates i.e. they still need to be adjusted by the offset value at the top.

Comment 6

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

Sorry for the delayed response.

(In reply to Ray Shanley from comment #5)
> This does not give the absolute screen co-ordinates i.e. they still need to
> be adjusted by the offset value at the top.

I'm a little confused what you mean by "absolute screen co-ordinates". To me that means relative to the physical hardware screen, which means you also need to account for the android notification bar at the top of the screen. How do you do that?

Also, something to consider, if this is for ui test automation, is to just disable the dynamic toolbar behaviour entirely by setting the browser.chrome.dynamictoolbar pref to false. I believe that will lock the dynamictoolbar in place and the innerHeight will then not include that extra height, which might work for you.

Comment 7

[Ray Shanley]

The thing is we already have a solution that works on all other browsers (Android Stock, Chrome, Opera) and it even works on iOS Safari and Internet Explorer on Windows phone. The only brower where it doesn't work is Firefox.

Comment 8

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

That doesn't answer my questions though. I still don't have a good idea of how your system works so I don't know if it's a valid use case or not from our point of view. Even if your system works on all other browsers it might be missing some small piece which does nothing on the other browsers and fixes it for you on Firefox. It doesn't necessarily indicate something needs to change in Firefox.

Comment 9

[Ray Shanley]

Attachment: Different use case for window.innerHeight

I've thought about this again and created a use case which is completely separate from my use case. The use case is as follows: you want an element to appear near each corner at all times. Please take a look at the attached test.

Comment 10

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

Attachment: Rebuttal to attachment 814916

Here is a better way to accomplish that, which doesn't rely on window.innerWidth or window.innerHeight. You can even get rid of the setInterval call if you don't want to keep updating the display of innerWidth and innerHeight; the boxes will still smoothly track the edges. (I tested in the Responsive Design View in Firefox desktop).

Comment 11

[Reinhold Degenfellner]

Hi Kartikaya,

I have another view of things to offer. When we have a look at the desktop firefox implementation innerHeight will always represent the actually visible  height of the window no matter whether there is a 
addressbar present or not. see https://developer.mozilla.org/en-US/docs/Web/API/Window.innerHeight
I think what we are talking here is "visual viewport" vs. "layout viewport".
According to other resources I could find e.g. http://www.w3.org/TR/cssom-view/#dom-window-innerheight or http://www.quirksmode.org/mobile/tableViewport.html window.innerHeight should represent the "visual viewport" height.
What do think about that?
Another point of view might be, at the end of the day we all want browsers that behave as similar as possible as far as HTML, javascript and DOM is concerned, so why not equalize the behaviour here with other browsers?

thx

Comment 12

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

Thanks Reinhold; there is some discussion of this in bug 919437 and in the first few comments of this bug.

My argument is basically that the height of the "visual viewport" that the page is rendering to actually includes the height of the address bar, because in the "default" case the user will be looking at the screen with the address bar hidden. When the address bar is visible it can be thought of as either sitting on top of the content, or pushing the content down, but never actually resizing the content.

Perhaps the mockup at http://www.flickr.com/photos/61892693@N03/7003028197/in/set-72157629270239482 will help illustrate this. This is one of the early UX mockups of Fennec and although many things have changed since then, it illustrates how the content "layer" is different from the URL bar "layer". The size of the content layer corresponds to the visual viewport is never actually resized; it just shifts down sometimes to show the URL bar, or the URL bar comes down and obscures part of it. Does that help with visualizing what I mean?

Comment 13

[Ray Shanley]

We will use the property you suggested (browser.chrome.dynamictoolbar = false) but we still believe the behaviour is wrong for the mentioned case. And it should be fixed because the website developer has no opportunity to get the real visual viewport size. This also has the effect that we have to tell our customers that they need to set this firefox property for the product to work properly while on all other browsers it just works out of the box.

Comment 14

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

For bug posterity, there was some more discussion of this over in bug 943921.

Comment 15

[Adam Lafene]

Hi Kartikaya,
I too have encountered the problem with Firefox on Android not taking the address bar into account when calculating window.innerHeight(). I found this thread and have followed it with interest. If I understand you correctly, you are arguing that the address bar is actually sitting on top of the visual viewport. I'm afraid I cannot agree with this assessment because when the address bar appears, fixed-positioned elements change their position relative to it. Take this simple example of a fixed menu: http://getbootstrap.com/examples/navbar-fixed-top/
The css for the menu element on this page is "position:fixed" with "top:0". If the FF address bar were to truly sit on top of the viewable area then the bottom of it would be 60px from the top of the viewport, thus obscuring the fixed element (which is positioned with CSS to be at the top of the viewable area, always). As you can see if you look at the page on FF mobile, this isn't so and in fact this behaviour would render sites with fixed menu bars unworkable in mobile Firefox.

Comment 16

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

Hm, you raise an excellent point. Our behaviour is inconsistent in the situation you describe.

Comment 17

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

With the new dynamic toolbar implementation (bug 1180295) this issue should be resolved. On the latest nightly for example the window.innerHeight changes depending on whether or not the toolbar is visible.