This question already has answers here:
How do you detect between a Desktop and Mobile Chrome User Agent?
(2 answers)
Closed 6 years ago.
I'd like to detect Chrome on mobile devices only e.g Chrome for Android, Chrome for iOS. What's a reliable way to do this?
EDIT 1: In case you're wondering why...
The mobile version of Chrome annoyingly changes the viewport height when the address bar shows/hides. Because my site relies so heavily on vh units, the user experience while scrolling on Chrome for Android and Chrome for iOS is ugly.
My solution is to wrap the entire site in a limited height container and relegate the scrolling to it. This prevents the window from scrolling, thus preventing the address bar from hiding. The only problem is that on desktop browsers scrolling becomes problematic because my layout contains fixed elements that obscure the wrapping container's scrollbar. Seeing as I may not ever find a solution to that problem, the best way forward for me is to detect Chrome on mobile devices, and apply the new layout only then.
EDIT 2:
The answers given in this question do not work for me. They detect Chrome even on Safari and the stock browser.
Search in user-agent-string and look for Chrome and (Android or iOS).
More info: http://www.useragentstring.com/
Related
Firstly, I'm well aware that this question has been asked before but there's never been a solution to fix the issue across all devices.
It's been asked at vh / % units and keyboard on mobile devices
, Ignore or disable mobile viewport resize due to keyboard open for text inputs on mobile web?
, and Android Keyboard shrinking the viewport and elements using unit vh in CSS.
I have researched this and tried a few JavaScript & jQuery methods but I can't seem to find a solution that works.
When the keyboard opens in mobile it shrinks the height of the viewport, text and inputs that have been sized with vh all get shorter. I need a way of calculating the initial page viewport height when it loads and then sticking with that height even if the viewport shrinks so that all page items are the same height as if the keyboard wasn't there.
Below is an example of how the inputs look before and after keyboard activation then to the right there's an example of the desired behaviour. I'd like to base vh on the initial height of the viewport for mobile as headers, text, icons and inputs are all sized via vh.
Any help would be appreciated.
EDIT
This question was originally posted on October 30th 2019. This update is being added on July 15th 2020 now that I've had time to look into these briefly after remembering this question a week or so ago. Microsoft's switch to Chromium has been beneficial in many ways but has now caused Chrome to acknowledge this properly with their latest announcement under the heading of Scrolling
How virtual keyboards affect - or don't affect - viewport units in different browsers. (Note recent work from Microsoft Edge on a VirtualKeyboard API that may help here.)
You can read the blog post titled Improving Chromium's browser compatibility in 2020 by clicking it and more about Intent to Prototype: VirtualKeyboard API by clicking that too. Hopefully this helps someone who finds this question in the future.
Chrome used to improperly exclude the scroll bar in its media queries. This means that with 1000px of visible space and a 17px scroll bar, other browsers would report 1017px as a width so far as Media Query is concerned, but webkit browsers (such as Chrome and Safari) did not do this.
These browsers could hit a specific size where a scroll bar would appear in one resolution, then change resolutions to another where it would appear, then it would go back to when it didn't... the solution caused an ugly blank space to appear where the scroll bar should, but it did not. It came out looking like a glitch, and the DOM resize events did not fire properly so it was not something you could react to properly in JS.
However, now in Chrome 29, this appears to have changed. Now they are going off of how the specification works and including the scroll bar in their media query calculations... just like Firefox and Internet Explorer (and how the specification says they should have all along). This fixes the bugs, but causes another problem in that the JS to try to detect the Chrome/Safari issue now will have false positives, because it is not a concern with newer versions of Chrome and I assume eventually Opera and Safari as well.
In light of all of this, I cannot find any information anywhere on when this was fixed in either Chrome or Webkit. I hate having to resort to browser version testing in my JS to work around these flaws, but I am just guessing blindly on Chrome 29+ for the moment as a temporary patch and would love an authoritative answer... I have tested in Safari 6.0.5, but the old method is still being used...
Does anybody know in what version of Chrome and/or Webkit this was fixed?
Chrome is no longer using the webkit engine as of Chrome v. 28 it now uses the Blink Rendering Engine. So no need to be detecting this for chrome unless you need it for previous versions.
For more on Blink: Blink Documnetation
For more on the Release: Next Web Article on Webkit/Blink Switch
This issue has been discussed here before, however, I don't get the suggested solution to work.
I want to change the scale / zoom of a webpage on a mobile safari via JS. The solution suggested by
How can I use JavaScript to set the zoom level on mobile safari?
Mobile Safari Web App Zoom issue
Is is possible to change page zoom in Mobile Safari via Javascript?
is to set the "viewport" meta tag.
I tried this, but the scale is not changed.
$('meta[name="viewport"]').attr('content', 'width=device-width, user-scalable:no');
When does safari interpret the viewport setting? Only when loading a page or also when the value is changed programmatically (what I would expect with repsect to the answers of the questions mentioned above)?
Did this behaviour change in some iOS version?
BTW: Where can a find a list of recognized arguments for viewport?
Many thanks for any suggestion!
So, by now we all know that iOS mobile Safari uses viewports (as does Android browser), rather than a 'standard' browser window. And this causes issues with overflow:hidden, and position:fixed.
This unfortunately is the same case with the iPad. I presume this is the case for other Android tablets too.
Rather than browser sniffing each time, is there an easy way to determine if the browser has a viewport or if it is standard?
Unfortunately, there's currently no good fix for mobile browsers' lack of support for position:fixed. The reason position:fixed is "broken" in the first place is because—among other things—no browser vendor knows exactly how to handle what happens when zooming in on the document. If you have some time to do some reading, I highly recommend the following articles, which will explain browser viewports and the problems surrounding fixed positioning on mobile in great, painstaking detail:
A tale of two viewports – part two — how viewports work and the problem of mobile browsers. (If you're not familiar with viewports in desktop browsers or want the background info, see also part one.)
The fifth position value does a fantastic job of explaining the problems surrounding position:fixed in a mobile browser, and suggests we might need a new position value – device-fixed.
Those articles will give you the why, but not the how to fix it. For a truly fixed position, you're mostly out of luck. However, if your goal is to have a fixed toolbar below scrolling content, there are a few ways to hack it. I've had success with iScroll.
Edit: The correct way to determine if you are running on a touch-based device is the following feature detection:
var isTouch = ('ontouchstart' in window);
ontouchstart is an event fired in mobile Safari and the Android browser. It is not present on desktop browsers, where you can just use overflow:auto and have regular scrollbars. If isTouch is true, you can then use iScroll.
Try media queries: you can include stylesheets, or apply parts of a stylesheet conditionally, based on the device and viewport dimensions the browser reports.
This article gives a decent enough introduction: http://www.alistapart.com/articles/responsive-web-design/
Android 3.0 (Honeycomb) now properly supports overflow scrolling in its browser. In older versions of Android, I've had to write my own JavaScript to scroll content within internal frames, overflowed content, and other elements to compensate for this issue. This shortcoming has been documented in the Android bug tracker with issues 2118, 6864, 7776, and a few other similar issues.
With the new release of Android, I'd prefer the browser handle this feature itself, if it's capable. Is there a way to sniff for support of this aside from just sniffing the user agent? I'd prefer to check for support of the feature over hacky user agent sniffing.
I've tried checking support of the scroll event, but both old Android browsers and Honeycomb seem to already have this event.
jQuery mobile also doesn't seem to check for support of overflow scrolling. They only detect whether or not the device supports touch events.