{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 在下西门庆 的问题《Keyboard orientation and media query bug (app mode》','https://www.manongdao.com/q-400843.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
- Add this webpage to your iOS7 home screen
- Open it, and focus the input field (the keyboard pops up)
- The text turns red, as the phone thinks it is in landscape mode
Is there any way around it? Or should we just blame Apple?
Note: This problem only occurs in app-mode, not in regular Safari browsing mode. And it worked fine in iOS6.
Code:
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<meta name="apple-mobile-web-app-capable" content="yes">
<style>
body {
color: blue;
}
@media (orientation:landscape) {
body {
color: red;
}
}
</style>
<body>
<h3>this text will go red when in landscape</h3>
<input type="text" />
</body>
This is clearly an iOS7 bug. In my application I found that I can reliably distinguish portrait mode from landscape mode even when focused on an input field with the on screen keyboard open using this media query:
I couldn't use orientation: landscape because the rule would get activated even in portrait mode if the keyboard is open.
I probably need a different rule for the iPhone but I haven't gotten that far yet.
The keyboard orientation bug effects some web browsers as well, not just app mode, but hopefully this can be used in either instance. It also seems to effect some Android devices.
Here's how I got around it for mobile web browsers:
The idea is that this query can only fire if a screen is either a perfect square or close to square, a scenario that pretty much only occurs when a keyboard is raised on touchscreen devices. The aspect ratio values I've used translate to between 1 and 1.5, so as an example a 16:9 screen has an aspect ratio of 1.7777778 (16/9) and would not be targeted. Once the MQ fires, you can re-style the effected elements. This doesn't fix the bug, it just conceals it.
If an OS doesn't contain the bug, this query will never fire, so if Apple fixes this, you don't need to change your code if you don't want to.
If a device is genuinely flipped to landscape mode, the aspect ratio only increases, and even moreso if the keyboard is raised, so the bug should never appear when a device is on its side.
To my knowledge, there are no devices with square/almost-square screens out there that would pick up this media query (at the time of writing), but please correct me if I'm wrong.
This has been tested on an iPhone 5s in Safari, Dolphin and Mercury browsers running iOS7, and in Chrome on an Android One X running Android 4.2.1 (which also experiences the same bug orientation bug with keyboards).
I also checked to see if it would fire on a Blackberry Bold 9780 (480x360), and it didn't. I don't quite trust this, as the resolution should have made it fall within the target range and it loaded the other MQs just fine, so perhaps it assesses the aspect ratio based around the physical size of the screen instead of the number of pixels. This is potentially an instance where the media query applies your bug solution to a screen that isn't experiencing the bug.
It's not perfect, but it got me out of trouble after a lot of headaches.
innerHeightis now affected by the keyboard being up in iOS7. If you check theinnerHeightvsinnerWidthwith the keyboard up when the device is in portrait you will find that theinnerHeight < innerWidthso maybe the browser's orientation check is as simple as that instead of using the device orientation straight up.