Response title
This is preview!
Move this topic
JQM 1.4: Preserve setting for height in viewport meta tag on page change
in jQuery Mobile
•
9 years ago
I just found out that JQM 1.4 rewrites the viewport meta tag on every JQM page change.
This creates some problems for one of my apps that needs the viewport height set to device-height - 20px (because of the statusbar plugin for Cordova/Phonegap 3.3). This is done in my app via jQuery and works fine on the first page. But after a page change JQM rewrites the viewport meta tag and thus breaks my fix.
So is there a way to have JQM preserve the viewport height parameter? Does it need to be rewritten on every page change?
I also tried to (re)set the viewport height parameter in the pageshow event for every page, but then the page transitioned to jumps after showing, so this is currently not an option.
BTW: Setting no height attribute in the viewport meta tag is not an option either since this will cause the native keyboard control on IOS break the fixed positioning of a tabbar at the bottom. Sigh.
Thanks!
This creates some problems for one of my apps that needs the viewport height set to device-height - 20px (because of the statusbar plugin for Cordova/Phonegap 3.3). This is done in my app via jQuery and works fine on the first page. But after a page change JQM rewrites the viewport meta tag and thus breaks my fix.
So is there a way to have JQM preserve the viewport height parameter? Does it need to be rewritten on every page change?
I also tried to (re)set the viewport height parameter in the pageshow event for every page, but then the page transitioned to jumps after showing, so this is currently not an option.
BTW: Setting no height attribute in the viewport meta tag is not an option either since this will cause the native keyboard control on IOS break the fixed positioning of a tabbar at the bottom. Sigh.
Thanks!
1
Replies(6)
I'm unfamiliar with that plugin (don't do much PhoneGap) but have used a similar feature in Rhodes. (native tabbar).
I don't understand why it is necessary for you to change the viewport height, unless this is a deficiency of this plugin.
If a plugin places it's own native control that takes up some part of the device height, the WebView will have a correspondingly shorter height. The viewport height should already be shorter by the height of the native control.
The WebView doesn't know the actual device height - only the height of it's window.
Is there some plugin option you are missing?
Edit: I looked at the docs for the status bar plugin. I see it deals with manipulating the iOS status bar. I don't think your issue has anything to do with this plugin at all, but a change that was made to status bar behavior in IOS7. By default, the status bar now overlays the top 20px of applications. However, this behavior can be changed, and the plugin has an option for this.
Leave a comment on watusiware's reply
I'm afraid I'm not missing an option (I whish I were though) :)
The statusbar plugin takes up the top 20px of the device's screen and the UIWebView is resized to 460px height (on an iPhone 4s). But when you set the height attribute of the viewport metatag to device-height, it thinks it's 480px high (which is actually correct since the device height is 480px and not 460px). No way of hacking into the viewport itself AFAIK. I guess this relates also to
https://issues.apache.org/jira/browse/CB-4999
where the author of the statusbar plugin (?) writes
"The UIWebView is already correctly sized, and takes into account the statusbar already. The meta tag viewport implementation of the UIWebView does not take into account the statusbar – thus you will have to remove the "height=device-height" value"
Problem with that is if I remove this parameter, the native keyboard of IOS breaks the fixed position of a tabbar (see my first post).
Here is what I get when I check for heights within my phonegap app before resizing the viewport (iPhone 5s in simulator):
2014-01-24 18:03:28.880 BIRU-WP[1284:70b] Device Display:
2014-01-24 18:03:28.881 BIRU-WP[1284:70b] $('window').height()..: 568
2014-01-24 18:03:28.881 BIRU-WP[1284:70b] window.innerHeight..: 548
2014-01-24 18:03:28.882 BIRU-WP[1284:70b] $('document').height(): 568
2014-01-24 18:03:28.882 BIRU-WP[1284:70b] body.clientHeight...: 566
2014-01-24 18:03:28.882 BIRU-WP[1284:70b] body.scrollHeight...: 568
2014-01-24 18:03:28.883 BIRU-WP[1284:70b] body.offsetHeight...: 566
This is what I get after I set the height to -20px:
2014-01-24 18:12:47.590 BIRU-WP[2210:70b] $('window').height()..: 548
2014-01-24 18:12:47.590 BIRU-WP[2210:70b] window.innerHeight..: 548
2014-01-24 18:12:47.591 BIRU-WP[2210:70b] $('document').height(): 548
2014-01-24 18:12:47.591 BIRU-WP[2210:70b] body.clientHeight...: 546
2014-01-24 18:12:47.591 BIRU-WP[2210:70b] body.scrollHeight...: 548
2014-01-24 18:12:47.592 BIRU-WP[2210:70b] body.offsetHeight...: 546
The statusbar plugin takes up the top 20px of the device's screen and the UIWebView is resized to 460px height (on an iPhone 4s). But when you set the height attribute of the viewport metatag to device-height, it thinks it's 480px high (which is actually correct since the device height is 480px and not 460px). No way of hacking into the viewport itself AFAIK. I guess this relates also to
https://issues.apache.org/jira/browse/CB-4999
where the author of the statusbar plugin (?) writes
"The UIWebView is already correctly sized, and takes into account the statusbar already. The meta tag viewport implementation of the UIWebView does not take into account the statusbar – thus you will have to remove the "height=device-height" value"
Problem with that is if I remove this parameter, the native keyboard of IOS breaks the fixed position of a tabbar (see my first post).
Here is what I get when I check for heights within my phonegap app before resizing the viewport (iPhone 5s in simulator):
2014-01-24 18:03:28.880 BIRU-WP[1284:70b] Device Display:
2014-01-24 18:03:28.881 BIRU-WP[1284:70b] $('window').height()..: 568
2014-01-24 18:03:28.881 BIRU-WP[1284:70b] window.innerHeight..: 548
2014-01-24 18:03:28.882 BIRU-WP[1284:70b] $('document').height(): 568
2014-01-24 18:03:28.882 BIRU-WP[1284:70b] body.clientHeight...: 566
2014-01-24 18:03:28.882 BIRU-WP[1284:70b] body.scrollHeight...: 568
2014-01-24 18:03:28.883 BIRU-WP[1284:70b] body.offsetHeight...: 566
This is what I get after I set the height to -20px:
2014-01-24 18:12:47.590 BIRU-WP[2210:70b] $('window').height()..: 548
2014-01-24 18:12:47.590 BIRU-WP[2210:70b] window.innerHeight..: 548
2014-01-24 18:12:47.591 BIRU-WP[2210:70b] $('document').height(): 548
2014-01-24 18:12:47.591 BIRU-WP[2210:70b] body.clientHeight...: 546
2014-01-24 18:12:47.591 BIRU-WP[2210:70b] body.scrollHeight...: 548
2014-01-24 18:12:47.592 BIRU-WP[2210:70b] body.offsetHeight...: 546
Leave a comment on Georg's reply
But when you set the height attribute of the viewport metatag to device-height,
I don't understand why you want to do that, though. Why are you setting the height attribute of the viewport metatag to device-height? You should *not* set the height attribute of the viewport metatag in jQuery Mobile projects.
Even if that worked (which it doesn't because jQuery Mobile assumes you will not be monkeying with this) it would be wrong, as clearly the window height is *not* the same as the device height. The device height is irrelevant.
Exactly. Plus, jQuery Mobile doesn't want you do do this."The UIWebView is already correctly sized, and takes into account the statusbar already. The meta tag viewport implementation of the UIWebView does not take into account the statusbar – thus you will have to remove the "height=device-height" value"
I think you've fallen into the trap of trying to write workarounds for your workarounds. Solve the real problem, which apparently you've previously written another post about:
(see my first post)
Leave a comment on watusiware's reply
Sorry if I have not been clear about some things.
I must to set the height attribute of the viewport meta tag, otherwise the native keyobard on IOS will break the fixed positioning of the tab bar (pushing the tabbar up above the keyboard) (bug in mobile Safari ( UIWebView for quite some time and still not fixed).
Setting the attribute to device-height when using the statusbar plugin in Phonegap makes pages that would normally fit onto the screen scrollable by 20px in JQM 1.4.
Not using the statusbar plugin would make scrollable pages on IOS 7 scroll underneath the statusbar, which does not look good at all (padding-top: 20px is no use on scrollable pages).
The fault lies not with the webview and not with the statusbar plugin since the webview is being told by the height-attribute of the viewport meta tag that it is as high as the device screen but which it actually is not because of the 20px statusbar above it. So no fault with the plugin and not fault with the webview.
It is that JQM *assumes* that the device height is the same as the webview height. This might be true in most of the cases but not on PhoneGap/Cordova + IOS7 + statusbar plugin. Actually the whole problem was introduced with IOS7 since before that the statusbar was not overlaying of the webview.
Setting the height attribute of the viewport meta tag to device-height - 20px via script solves the issue, but JQM overwrites this on pages changes.
So where should one try to solve the issue? It looked to me that JQM would be the likely candidate to address that, hence my question in the first place. If you have a better idea, I'd love to hear that! And thanks for your feedback so far!
I must to set the height attribute of the viewport meta tag, otherwise the native keyobard on IOS will break the fixed positioning of the tab bar (pushing the tabbar up above the keyboard) (bug in mobile Safari ( UIWebView for quite some time and still not fixed).
Setting the attribute to device-height when using the statusbar plugin in Phonegap makes pages that would normally fit onto the screen scrollable by 20px in JQM 1.4.
Not using the statusbar plugin would make scrollable pages on IOS 7 scroll underneath the statusbar, which does not look good at all (padding-top: 20px is no use on scrollable pages).
The fault lies not with the webview and not with the statusbar plugin since the webview is being told by the height-attribute of the viewport meta tag that it is as high as the device screen but which it actually is not because of the 20px statusbar above it. So no fault with the plugin and not fault with the webview.
It is that JQM *assumes* that the device height is the same as the webview height. This might be true in most of the cases but not on PhoneGap/Cordova + IOS7 + statusbar plugin. Actually the whole problem was introduced with IOS7 since before that the statusbar was not overlaying of the webview.
Setting the height attribute of the viewport meta tag to device-height - 20px via script solves the issue, but JQM overwrites this on pages changes.
So where should one try to solve the issue? It looked to me that JQM would be the likely candidate to address that, hence my question in the first place. If you have a better idea, I'd love to hear that! And thanks for your feedback so far!
Leave a comment on Georg's reply
Not using the statusbar plugin would make scrollable pages on IOS 7 scroll underneath the statusbar, which does not look good at all (padding-top: 20px is no use on scrollable pages).
Did you try setting StatusBar.overlaysWebView to false?
So where should one try to solve the issue?
It doesn't need to be solved. You need to solve the problem with your tab bar, which you didn't mention initially in your post. That's what I mean by writing workarounds for workarounds.
There's an easy solution pointed-out on another post here just this morning. Hide the tab bar when an input is focused. It will be underneath the keyboard and not visible anyway.
StatusBar.overlaysWebView
On iOS 7, make the statusbar overlay or not overlay the WebView.
StatusBar.overlaysWebView(true);
Leave a comment on watusiware's reply
Yes, that's what I am currently doing to prevent the underscroll on IOS7.Did you try setting StatusBar.overlaysWebView to false?
You need to solve the problem with your tab bar, which you didn't mention initially in your post.
Yes, I can solve the issue with the tabbar by hiding it on input. But this would probably still make my pages scroll by 20px when using the statusbar plugin since JQM modifies the the viewport meta tag and sets the height attrib to device-height.
I could hide the status bar to solve that, but this is considered bad programming unless there is a good reason to hide the statusbar (like on full screen maps for example).
What I will look into now is to work with an empty fixed header with a height of 20px. This might just do the trick.
Leave a comment on Georg's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to Georg's question