Closed Bug 904078 Opened 11 years ago Closed 11 years ago

window.innerHeight- reports higher value than actual height

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Version:
23 Branch
Platform:
x86
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox26 wontfix)

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox26 --- wontfix

People

(Reporter: benyr, Assigned: kats)

References

Details

Attachments

(1 file)

Test case
2.85 KB, text/html
Details 
User Agent: Mozilla/5.0 (Windows NT 6.2; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

in firefox 23 for android
window.innerHeight reports incorrect value
OS: Windows 8 → Android
What device? Do you have a test case that demonstrates the problem?
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> What device? Do you have a test case that demonstrates the problem?

in motorola razr and samsung s3.
i calculate the page height of my webapp, so i can size my html elements to fit exactly the page size. and everything worked in all browsers, but now it dosen't work in firefox 23 for android
There are many ways to do what you are describing. Please attach a test case so we can see exactly what you are doing and figure out which code needs to be fixed.
it's very simple i'm just taking window.innerHeight.

let's say that i want to put nav bar at the bottom of my page and the nav bar height is 60 pixels and i want to put the content div above him, so if i got that innerHeight is 500 pixels than the content div will be 440 pixels and the nav bar will be exactly at the bottom of my page.
but in new firefox the nav bar is outside the page because innerHeight is 48 pixels higher than actual height.

i'll try to attach example later
i wrote simple test page, but in that simple page innerHeight is ok.
i'll try to find what causing the problem...
found the problem:

i'm hiding the url in my webapp (when supported by browser)
so i have a - div that is 2000 pixel height (because scrollTo needs the page to be higher than the screen size) 

that div causes the new firefox to add another 48 pixels (depends on device) to innerHeight.
This sounds like expected behaviour then. Can you not use position:fixed to position your navbar at the bottom of the screen instead? That's what it's meant for, and we should support that case fine. If you have a page that is 2000 pixels tall then the innerHeight will be larger because it accounts for the height of the toolbar that can be scrolled off the page.

Marking this bug as invalid based on your description of what you're doing. If you have an actual test case that you think is behaving wrong in Gecko feel free to attach it and reopen the bug.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
i think this is wrong behaviour, because if i want the content above the navbar to fit the page i cant do it anymore.

and in the desktop it behaves different.

and even if i remove the 2000 px div, when changing to landscape -- then innerHeight is wrong again because portrait mode is higher.

so even if you think it's not wrong - the user need away to know the size of toolbar and the behaviour of the browser because its not cross-browser in firefox itself.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Like I said, you need to attach a test case that demonstrates the problem.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9)
> Like I said, you need to attach a test case that demonstrates the problem.

<!DOCTYPE html>
<html>
    <head>
        <title>Firefox Test</title>
        <!-- Meta -->
        <meta charset="UTF-8" />
        <meta content='width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no' name='viewport' />
        <meta name="apple-mobile-web-app-capable" content="yes"/>
        <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent"/>

        <!-- CSS -->
        <style>
            *{
                font-family: 'Terminal Dosis',sans-serif;
                border: 0 none;
                margin: 0;
                padding: 0;
                text-decoration: none;
                list-style: none outside none;
                outline:none;
            }

            #topPart{
                width: 100%;
                height: 0;
            }

            #bottomPart{
                background: green;
                width: 100%;
                height: 60px;
                border: 4px solid blue;
                /*padding: 5px;*/
                -webkit-box-sizing: border-box;
                -moz-box-sizing: border-box;
                box-sizing: border-box;
            }
            #page{
                width: 100%;
                height: 100%;
                background: rgb(42, 42, 42);
            }
        </style>

        <!-- Javascript -->
        <script>

            function AttachEvent(element, event, handler){
                if (element.addEventListener)
                {
                    element.addEventListener(event, handler, false);
                }
                else if (element.attachEvent)
                {
                    element.attachEvent('on' + event, handler);
                }
            }

            function onOrientationChange() {
                setTimeout(function(){
                                    topPart.style.height = (window.innerHeight - 60) + 'px';
                                    },1000);
            }

            function startApp(){
                // alert(window.innerHeight);
                topPart = document.getElementById('topPart');
                topPart.style.height = (window.innerHeight - 60) + 'px';
                var supportsOrientationChange = "onorientationchange" in window;
                var orientationEvent = supportsOrientationChange ? "orientationchange" : "resize";
                setTimeout(function(){
                                    AttachEvent(window, orientationEvent, onOrientationChange);
                                    },1000);
            }
            window.onload = function (){
                setTimeout(startApp, 2000);
            };
        </script>
    </head>

    <body>
        <div id="page">
            <div id="topPart"></div>
            <div id="bottomPart"></div>
        </div>
    </body>
</html>
the example above is not working when changing from portrait to landscape
Attachment #790764 - Attachment mime type: text/plain → text/html
Ok, the behaviour on this page does appear to be wrong. Tested on the latest nightly on a Nexus 4.
Blocks: dynamic-toolbar
Status: UNCONFIRMED → NEW
status-firefox26: --- → affected
Ever confirmed: true
So I spent some going through the dynamic toolbar code and fixing a couple of outstanding bugs in that code (patches on bug 898877). I also looked at this bug, and as it turns out, I think the behaviour here is actually as sane as we can make it. The first thing I want to note is that if you take out the timeout in your orientation change listener, the page works just fine.

The reason for this is that for the toolbar-hiding code to work properly, the innerHeight of the page actually depends on what you put in the page. There are three cases here. To explain with numbers, I'm going to talk about the Nexus 4 device, which has a browser screen area of 768 x 1134 pixels. The browser toolbar takes up 96 pixels of height here, leaving 1038 pixels for the webpage.

1) If your page is really short (less than or equal to 1038 pixels), we must keep the toolbar visible at all times, then we will size the innerHeight to be 1038. This allows stuff stuck to the bottom of the page (like in your example) to actually be visible at the bottom of the screen.
2) If the page height is greater than 1038 but less than 1134 pixels, we will again keep the innerHeight at 1038, but allow the page to scroll a little bit. Because the page is less than 1038, it doesn't make sense to allow the dynamic toolbar to scroll off the screen, so we will just keep it there always.
3) If the page height is greater than or equal to 1134 pixels, we will now increase the innerHeight to 1134, and allow the toolbar to scroll off the screen.

This is all fine and works well. The problem happens when the page size itself changes as a response to innerHeight. It's very easy to get stuck in an infinite loop where the page changes it's height, we change the innerHeight as a response, and the page changes its height again in response to that, and so on. To prevent this from happening, we do this thing where we first size the innerHeight to 1038, and lay out the page. If the page height is less than 1134, then all is fine (we are either in case 1 or 2 above) and no further action is needed. If the page height is 1134 or larger, then we are really in case 3 so we need to increase the innerHeight to 1134, and so we do that.

In your test page, because you don't respond to the rotation event right away, you end up in case 3. If you respond to the rotation event right away and move the div without a setTimeout call, then we end up in case 1 and everything is fine.

As an aside, it's quite possible for pages to get stuck in an infinite loop where they keep changing their size in response to the innerHeight change, and we keep changing the innerHeight because their size is changing, and so the page will keep bouncing between states 1 and 3. In practice this doesn't happen because you'd have to go out of your way to design a webpage that does this. And even then, we have a throttle that limits the switching to half a second.

So anyway, that's the explanation of what's going on and why the page works fine without the setTimeout and fails with the setTimeout. I'm sorry but it's a really hard problem to fix the setTimeout case without either adding some non-standard property or breaking some other use case.
Marking this wontfix as per my last comment.
Status: NEW → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → WONTFIX
Assignee: nobody → bugmail.mozilla
i tried it an you right it works on android device,
but its not working in the browser under firefox os on keon device.
Status: RESOLVED → REOPENED
OS: Android → Gonk (Firefox OS)
Resolution: WONTFIX → ---
Please file a new bug for that, it is a completely different code path used there, and using this bug for that will get confusing.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
status-firefox26: affected → wontfix
OS: Gonk (Firefox OS) → Android
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: