Bug Tracker

Opened 6 years ago

Closed 4 years ago

#12974 closed bug (migrated)

$('html').outerHeight(true) returns inconsistent results across browsers

Reported by: jon@… Owned by: jon@…
Priority: low Milestone: None
Component: css Version: 1.8.3
Keywords: Cc:
Blocked by: Blocking:


I am receiving inconsistent results between browsers when using $('html').outerHeight(true). My goal is to retrieve the actual rendered height of the document. I am avoiding $(document).height() because if the rendered height is smaller than the window height, the window height is returned. On firefox, $('html').outerHeight(true) works correctly, but on IE8 the window height is always returned. Observe using the example at:


If I run this in Firefox I see:


Notice the html height matches the document height.

If I run this in IE8 I see:


Notice the height (approx) matches the window height and not the document height.

Change History (11)

comment:1 Changed 6 years ago by mikesherov

Owner: set to jon@…
Status: newpending

Thanks for contributing! What about just $('html').height()? Does that give consistent results? We don't really support $('html').height() currently considering the browsers don't give us useful info as you've discovered, but I'm just curious.

comment:2 Changed 6 years ago by jon@…

Status: pendingnew

In that case, what is the preferred way to retrieve the actual content height? $(document).height() works well when the content is larger than the window, but when the content is smaller than the window $(document).height() returns the window height. $('html').height() appears to be correct on Firefox, but not IE. Is there a better solution?

I have updated the test case to show height() as well as outerHeight(true). Same results. This is some console output from running the test case.





comment:3 Changed 6 years ago by mikesherov

Status: newpending

Thanks again for contributing! Your test case is missing the opening html tag. Can you update it please, considering I can't edit it as you are hosting it on your own server instead of submitting a jsfiddle?

comment:4 Changed 6 years ago by Jon Dufresne <jon@…>

I have fixed the mistake in the test case. The results are the same. I have uploaded the newest test case to the same location.

I also made an identical version using jsFiddle. This version also demostrates the same bug. See the fiddle version at http://jsfiddle.net/GmKmt/6/

comment:5 Changed 6 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

comment:6 Changed 6 years ago by jdufresne

What information is requested that was not provided? This is still reproducible and all information requested was provided.

comment:7 Changed 6 years ago by dmethvin

Resolution: invalid
Status: closedreopened

Not sure why this was auto-closed, it should have noticed you were the OP.

comment:8 Changed 6 years ago by dmethvin

Status: reopenedopen

comment:9 Changed 6 years ago by timmywil

Component: unfiledcss
Priority: undecidedlow

comment:10 Changed 6 years ago by m_gol

Test updated for 1.x-master: http://jsfiddle.net/GmKmt/8/

comment:11 Changed 4 years ago by m_gol

Resolution: migrated
Status: openclosed
Note: See TracTickets for help on using tickets.