Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Core.Browser broken on iOS when launching a page as a favorite from the Home Screen #2480

bcherny opened this Issue · 7 comments

5 participants


iOS passes a different user agent string to window.navigator when viewing a page in Safari vs. when launching it from the home screen (after adding it as a shortcut to the home screen). Using iOS 6.1.2 on an iPhone 4, I get the following:

When viewing in Safari (works as expected):

> navigator.userAgent.toLowerCase()
"mozilla/5.0 (iphone; cpu iphone os 6_1_2 like mac os x) applewebkit/536.26 (khtml, like gecko) version/6.0 mobile/10b146 safari/8536.25"

> navigator.userAgent.toLowerCase().match(/(opera|ie|firefox|chrome|version)[\s\/:]([\w\d\.]+)?.*?(safari|version[\s\/:]([\w\d\.]+)|$)/) || [null, 'unknown', 0]
["version/6.0 mobile/10b146 safari", "version", "6.0", "safari", undefined]

When launching from homescreen shortcut (broken):

> navigator.userAgent.toLowerCase()
"mozilla/5.0 (iphone; cpu iphone os 6_1_2 like mac os x) applewebkit/536.26 (khtml, like gecko) mobile/10b146"

> navigator.userAgent.toLowerCase().match(/(opera|ie|firefox|chrome|version)[\s\/:]([\w\d\.]+)?.*?(safari|version[\s\/:]([\w\d\.]+)|$)/) || [null, 'unknown', 0]
[null, "unknown", 0]

HI @eighttrackmind; first thing is, you shouldn't use browser detection. We'd deprecate / remove it entirely, if we didn't owe it to legacy users to keep it.

If you need to detect iOS homescreen installs, use the proprietary window.navigator.standalone property.

@fakedarren fakedarren closed this

@fakedarren thanks for the quick response! If you're not maintaining the code anymore, maybe move it to a "legacy" module, or add a message to the build page that it's no longer being patched? When I use something like MT, my expectation is that it's bulletproof; if not, it would be nice to have some sort of indicator as a courtesy :)


@ibolmo sorry, bad choice of acronym on my part - I meant MooTools. When I use any big library (jQuery, MooTools, Closure) my assumption is that all code is well tested, and hopefully well documented. That (in my mind) is the big advantage of large libs over micro frameworks that do the same thing in a lot less code. If an officially supported feature is broken, it seems to me that it should either be fixed or deprecated, not left hanging; if left in this grey area, faulty code distributed through official channels has the potential to break many users' code without their knowledge. With almost 10% market share, MooTools has a lot of users. As a public service, the very least we could do is let users know about the potential issue.


Browser detection is bad. I agree.
But sometimes there is no quick or obvious solution to detect strange browser behavior.
For example:
If I want to JSON.stringify arrays of other windows, IE always encodes them as objects (perhaps because of "(win.myArray instanceof Array) === false)".

In this "feature" detection I currently have to use eval which is always a bad idea.
So here browser detection is a quick (and dirty) way to finish your task without implementing a good crossbrowser feature detection.

So I too think Core.Browser should be updated or moved to More or something similar.


It is not that it's legacy code, but I cannot remove it because would break backward compatibility and many applications.

But can't you just use Browser.Platform.ios?


@arian In my case I needed the version string as well as the browser and device.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.