Response title
This is preview!
I'm having issues getting a reliable $(window).height() on Mobile Safari on iPhone. I am trying to size a window to the available viewport height. This is for my jquery.mobile.iscrollview plugin for jQuery Mobile.
Near as I can tell, the issue is this: the browser always starts-up with the address bar (at the top of the browser) shown. This reduces the available space by 60px, which is the height of the address bar. So, $(window).height() reports a size 60px less than what is really available (assuming you don't want the address bar to show.)
But jQuery Mobile then scrolls-up to hide the address bar. I guess there is a way of scrolling everything, including the chrome? I'm a bit fuzzy on this.
(The address bar gets pushed back down then up on page changes - which is annoying - but I think a separate issue. I think I've read it manages to prevent this completely at least when linking from a listview.)
But, in any case, when the address bar gets pushed back up, that increases the available viewport height by 60px. But Mobile Safari does *not* fire a resize event when this happens! So, there's no way (or is there?) to find out that the viewport height has changed. Is there some other event (maybe that jQuery Mobile itself fires) when this happens?
I'm leery to just detect iPhone and add 60px to the page height. It seems to work, but it feels like a time bomb. ;)
The problem doesn't occur if you save to the desktop, because then you get a chrome-less browser window. As well, it doesn't occur when using a UIWebView from Phone Gap, etc. (same reason).
I tried binding to the updatelayout event, in addition to resize and orientationchange, but that didn't help.
It seems maybe some new event is needed, or else JQM should use the resize event in this case. It does seem to be a quirk of Safari Mobile, but JQM should try to hide browser differences.
Clearly, JQM itself is able to cope with this, because fixed toolbars do go where they are supposed to (i.e. when they fade back after a scroll). So, it must know internally. (Yes, I also tried a scrollstop event, and that didn't help either...)
Near as I can tell, the issue is this: the browser always starts-up with the address bar (at the top of the browser) shown. This reduces the available space by 60px, which is the height of the address bar. So, $(window).height() reports a size 60px less than what is really available (assuming you don't want the address bar to show.)
But jQuery Mobile then scrolls-up to hide the address bar. I guess there is a way of scrolling everything, including the chrome? I'm a bit fuzzy on this.
(The address bar gets pushed back down then up on page changes - which is annoying - but I think a separate issue. I think I've read it manages to prevent this completely at least when linking from a listview.)
But, in any case, when the address bar gets pushed back up, that increases the available viewport height by 60px. But Mobile Safari does *not* fire a resize event when this happens! So, there's no way (or is there?) to find out that the viewport height has changed. Is there some other event (maybe that jQuery Mobile itself fires) when this happens?
I'm leery to just detect iPhone and add 60px to the page height. It seems to work, but it feels like a time bomb. ;)
The problem doesn't occur if you save to the desktop, because then you get a chrome-less browser window. As well, it doesn't occur when using a UIWebView from Phone Gap, etc. (same reason).
I tried binding to the updatelayout event, in addition to resize and orientationchange, but that didn't help.
It seems maybe some new event is needed, or else JQM should use the resize event in this case. It does seem to be a quirk of Safari Mobile, but JQM should try to hide browser differences.
Clearly, JQM itself is able to cope with this, because fixed toolbars do go where they are supposed to (i.e. when they fade back after a scroll). So, it must know internally. (Yes, I also tried a scrollstop event, and that didn't help either...)
1
