This is what I have in my head section of index.html:
<head>
<meta charset="utf-8">
<title>MeasurementProtocols</title>
<base href="/index.html">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="icon" type="image/x-icon" href="./assets/icons/apple/touch-icon-ipad.png">
<link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet">
<link rel="manifest" crossOrigin="use-credentials" href="manifest.json">
<link rel="apple-touch-icon" href="./assets/icons/apple/touch-icon-iphone.png">
<link rel="apple-touch-icon" sizes="120x120" href="./assets/icons/apple/touch-icon-ipad.png">
<link rel="apple-touch-icon" sizes="152x152" href="./assets/icons/apple/touch-icon-iphone-retina.png">
<link rel="apple-touch-icon" sizes="180x180" href="./assets/icons/apple/touch-icon-ipad-retina.png">
<meta name="theme-color" content="#1976d2">
</head>
If I want to add the webpage to homescreen via an Apple device, the iPhone would take a screenshot as icon, although I added the icons to the index.html as apple describes it on: https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html
So what am I missing, or does it not work with having href directed to assets and not the mainfolder?
PWA with Icons don't work with authentication on a Webserver on iOS. Solution is to remove the Authentication.
While iOS 11.3 does support web app manifests, it does not yet support specifying icons this way. You'll want to include it in your manifest for other devices, but at least for now you'll have to use the following for iOS:
<link rel="apple-touch-icon" sizes="180x180" href="icon.png">
Specify the icon size, and include a URL.
Learn more at Apple's documentation here
There is also a website to automate the process linked here
Expanding on Hannes answer
PWA with Icons don't work with authentication on a Webserver on iOS
One possible fix is to allow anonymous access to JUST the icons.
Example with Azure Easy Auth:
Create rule file in your public/wwwroot:
Note: This feature, URL Authorization Rules, was a preview feature that may be unsupported/deprecated moving forward (>=2021-04). Unclear what the replacement is, if any.
authorization.json
{
"routes": [
{
"path_prefix": "/",
"policies": {
"unauthenticated_action": "RedirectToLoginPage"
}
},
{
"path_prefix": "/img/icons",
"policies": {
"unauthenticated_action": "AllowAnonymous"
}
}
]
}
Switch your Azure Authentication setting to: "Allow Anonymous Requests (no action)"
This should now allow your icons to show up when saving the page to homescreen on iOS device, but not allowing the rest of the app to be accessible prior to login.
Minor Note: Since all requests now default to "Allow Anonymous Requests (no action)", its important you have the catch all rule of "path_prefix": "/" - without it your whole app would be public. Since this feature (at least in Azure Web Auth) uses longest-prefix matching, order shouldn't matter and you should be able to craft the rules with either whitelist or blacklist approach.
Related
I've had a look at other solutions proposed to other similar questions on StackOverflow and I can't seem to get my favicon to display for my Rails page in Chrome (at least on the desktop, it works for Chrome on my iPad weirdly).
I've tried having it as an .ico, as a .png, and currently have it as a Base64 string as proposed in response to a similar question. All of these work in Firefox, but will not work in Chrome.
The page is deployed using Heroku, and the link href tag is in the head tag.
The page is at https://www.resnate.com.
EDIT: Code:
<head>
<meta property="og:title" content="Resnate: The Music Social Network." />
<meta property="og:description" content="Music, Gigs and Merch." />
<meta property="og:image" content="/assets/previewimg2-c6c3bbb488ce1d2360bb605f93adc8421afe44813c1de1e324aa008858dbba18.png" />
<title>Resnate: Music, Gigs, Merch.</title>
<link rel="stylesheet" media="screen" href="/assets/application.self-a2388fc8a11c59fee992af9cba7099a53de4bd515465610aa19c43a3b90054f6.css?body=1" data-turbolinks-track="true" />
<link href='//fonts.googleapis.com/css?family=Lato:400,900' rel='stylesheet' type='text/css'>
<script src="/assets/jquery.self-c64a74367bda6ef8b860f19e74df08927ca99d2be2ac934e9e92d5fd361e0da4.js?body=1" data-turbolinks-track="true"></script>
<script src="/assets/jquery_ujs.self-d602bdfe68ffc63b9f9cc512872aa3cfff046228a0a36e90dd476e8ef54c1b09.js?body=1" data-turbolinks-track="true"></script>
<script src="https://js.pusher.com/2.2/pusher.min.js"></script>
<link href="data:image/x-icon;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAABmJLR0QAAAAAAAD5Q7t/AAAACXBIWXMAABYlAAAWJQFJUiTwAAAACXZwQWcAAAAgAAAAIACH+pydAAAC8klEQVRYw+2XsWscRxSHv5nZ273bVRw43BrLcEIGkwgRY8g/YHDhwq3BpcvgwrhyYRUOuFGVMmXAJJCgQn+Cgw3BRpGNweJUyE5njLGk273bvZt5KeZ0J4WTtCffKY1fuey83zfvzbx5TzXv3JPO1lt0GIIAiulaX8MVBdXZ8wSdrbe0N5qoKEK6vSmre1OVAMlzAAIdhqgoQlermHrsI+DcFEIhoDUI2CzDAToMCRCQbg9Tj7n4y89U6nUIDEpNFkBEoGfpfvzIm1u3sbstEAgGG1UQfH0GjKHd3ERp46knE3TEWWqNhtfYrzn4xzlUFNFubvL6xk10NQKlPjsSIgIiuE7OpZXH1OYa/RR7GwLgxZQ26GqErtVwaYbNczgphAg6itBJ7BX0XmqH/oIRq0ApXJpx9sZ1znx/BZumoPSY4g6TJOw8+4sPK6tgNKNSGoxaq5TCFgUzi99Sv3YV6fVQQXCc5EH9/hrX6fD+tz8wcW3kf0d6FWsB2Fr6kWyjiUmSUuI2TYnn57jw8MHAx2F29Lb6Yc82Nmm9+BsVVrCt9NCDKSKYmQQpugzyfEzqSsXVJDEqrPDV4gIzl7/zVUz/B8IJKopoPX/B7to6pn/wjrPSiXVpRrLwDefu/jDyTOx9e/dome0/n5V1Wx5gb5fAyLyKtR7KjVe8xgPoh10Zc/it0OPVjDEv9+TtC8CXQ1gaQCcx6for/ln+6chClK6/Grx+EwOwaYYUXXbX1vn05GmpUmzTbAIA4huHeL4ByJiPUeOAjxMBKGMAmF26f6LneL+PsQBEBB2GtNZeoqvVz2pIWmsv0WHoW7NyAMq3UknMh5VV3v/6+0RaMtduM6rV3wcgiAjiLK7jhwaMLv2sHs4guHYb18kRZ/uRGEZjCKA1kufUGg0urTyeWlvur/AwncFAQ6C3vUOlXqc215jaYNLb3mG/ZoDys5rNMt7cun1qo5mqBH4wcUWB5DkO/Lh0CrY3nLqiIKjOngf438bzfwFHKVzQwuVyewAAAFl6VFh0U29mdHdhcmUAAHja88xNTE/1TUzPTM5WMNMz0rNQMDDVNzDXNzRSCDQ0U0jLzEm10i8tLtIvzkgsStX3RCjXNdMz0rPQT8lP1s/MS0mt0Msoyc0BAK1OGKx0FS5rAAAAIXpUWHRUaHVtYjo6RG9jdW1lbnQ6OlBhZ2VzAAB42jMEAAAyADIMEuKEAAAAInpUWHRUaHVtYjo6SW1hZ2U6OmhlaWdodAAAeNozNLIwAgACAADOvq1X/gAAACF6VFh0VGh1bWI6OkltYWdlOjpXaWR0aAAAeNozNLIwAQACAgDQ2j98IAAAACJ6VFh0VGh1bWI6Ok1pbWV0eXBlAAB42svMTUxP1S/ISwcAEXsDeF85R+IAAAAgelRYdFRodW1iOjpNVGltZQAAeNozNLY0NjcyNTI3BAALOQIJ9tf2MgAAABl6VFh0VGh1bWI6OlNpemUAAHjaM7LMTgIAAq8BOcs8cVIAAAAcelRYdFRodW1iOjpVUkkAAHjaS8vMSbXS19cHAAyaAmiUQFGqAAAAAElFTkSuQmCC" rel="icon" type="image/x-icon" />
<meta name="csrf-param" content="authenticity_token" />
<meta name="csrf-token" content="nM46FYSVzSqJFGHsAMGU/IrPXSNExiq25L5Q7vJp2ZP+f3uj1u9isqrpgNna/mAl1X0eABdwsP6YYt8qzgDHTA==" />
<!--[if lt IE 9]>
<script src="https://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
</head>
I know this question is two years old now, but as I have been struggling with this exact problem for 3+ hours surfing the net without finding a solution to my case (I was doing everything people suggested in all its flavors) and I have just suddenly make it work, I think I'm going to post my experience just in case I can save the pain to the next victim.
My setup was exactly the same as OP's: Rails app with a favicon displaying in every single browser but Chrome. I tried to follow #toddmetheny answer without success.
It turns out that as this app I'm working in loads a whole lot of scripts inside <head>, where you place the favicon <link> tags becomes important. I don't really know why this happens (would be much appreciated if someone could either confirm or destroy my theory), but I guess that while Chrome is loading those scripts, as it has not yet found any <link> tag referencing a favicon, it requests the default /favicon.ico. I noticed this while looking at the Network tab: Chrome always requested /favicon.ico while the other browsers requested the one referenced in the <link> tag as expected.
I don't know if this might have been the cause to OP's problem (as I see he loads some scripts too), but the solution was as simple as moving the favicon_link_tag block to the top of <head>, just after <meta> tags.
Hope this helps some desperate folks out there!
Try using the rails helper favicon_link_tag.
Make sure your icon is saved in app/assets/images. Clear your browser cache to ensure you're using the latest.
How to get favicon website with Chromium Embedded Framework? I could look at the source code and get the url of the icon, but some sites, like Facebook, do not use a standard procedure to add a favicon, then, how do I get the favicon? Thanks.
The rules for the favicon are all explained on the Wikipedia page.
The standards use a link element with a rel attribute in the <head> section of the document to specify the file format, file name and a location can be specified for any Web site directory.
You need to look, inside the <head> element, for link elements of this form:
<link rel="shortcut icon" href="http://example.com/myicon.ico" />
or
<link rel="icon" type="image/vnd.microsoft.icon"
href="http://example.com/image.ico" />
If you don't find such links, then use the fall back of looking for favicon.ico at the root directory.
I'm not certain why you think that Facebook don't follow the standard. I just looked at an FB page which contained this:
<link rel="shortcut icon"
href="http://static.ak.fbcdn.net/rsrc.php/yP/r/Ivn-CVe5TGK.ico" />
It's not possible for websites to use some other mechanism to get favicons to browsers. The browsers follow the well-defined rules for getting favicons. If a website did something different, the browser would not find the favicon.
From this blog entry, the best practice for cross-browser supported favicons is to include
<link rel="icon" type="image/vnd.microsoft.icon" href="http://www.example.com/image.ico"> <!-- For good browsers. -->
<link rel="SHORTCUT ICON" href="http://www.example.com/image.ico"/> <!-- For Internet Explorer-->
The first link is for real browsers and the second is for ie rubbish. On some websites you will see type="image/x-icon" in the link tag. There was a time when this was the correct implementation, but image/x-icon has now been superceded by image/vnd.microsoft.icon which is now part of the IANA standard for MIME types.
By the way, older versions of ie just looked for a file name /favicon.ico which was hard-coded. If you wanted to be ultra safe, you should name your favicon as favicon.ico. Of course that does not help you if your domain hosts multiple web-sites for different purposes.
Note: If you don't need to support favicons for IE, then you are then free to use png, gif and jpg formats for your favicon, as indicated below...
<link rel="icon" type="image/png" href="http://www.example.com/image.png">
<link rel="icon" type="image/gif" href="http://www.example.com/image.gif">
<link rel="icon" type="image/jpeg" href="http://www.example.com/image.jpg">
CEF1 has a callback named OnFaviconURLChange that's called whenever the favicon URL for a page changes. CEF3 doesn't support this callback yet, according to this bug in the CEF issue tracker.
You need to implement a client handler and at least CefDisplayHandler. This class have the OnFaviconURLChange (not sure in what version did appear, but for sure is present in branch 2357 and later).
C++ prototype is:
void OnFaviconURLChange(CefRefPtr<CefBrowser> browser,
const std::vector<CefString>& icon_urls);
icon_urls usually contains a single entry (if any), which is the URL of the favicon.
Consider also checking the favicon URL for its security, I passed the URL to a HTMLayout application only to discover that was on a self-signed https:// resource and all sorts of wininet security error (InternetErrorDlg for example) started throwing all the place.
I have a simple app developed with jQuery Mobile and implemented in PhoneGap. It works fine in the iPad 4.3 simulator, but not on iPad 5.0 simulator and an actual iPad running iOS 5...
This is the head section of the html file:
<head>
<meta charset="utf-8"/>
<meta name="apple-mobile-web-app-capable" content="yes"/>
<meta name="apple-mobile-web-app-status-bar-style" content="black"/>
<meta content="width=device-width,minimum-scale=1,maximum-scale=1" name="viewport"/>
<link rel="apple-touch-icon" href="icon.png"/>
<link rel="apple-touch-icon" sizes="72x72" href="icon.png"/>
<link rel="apple-touch-icon" sizes="114x114" href="icon.png"/>
<title>App demo</title>
<link rel="stylesheet" href="scripts/jquery.mobile-1.0rc2.min.css"/>
<link href="css/style.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="scripts/jquery-1.6.4.min.js"/>
<script type="text/javascript" src="scripts/jquery.mobile-1.0rc2.min.js"/>
<script type="text/javascript" src="scripts/general.js"></script>
<script type="text/javascript" src="scripts/app.js"/>
</head>
When I run it on iPad simulator 4.3 everything works great. But on 5.0 it just shows a blank screen. Same with the actual iPad with iOS 5. If however I remove the script references it sort of "works" in that it shows the content of the HTML page, but of course without the styling and functionality of jQuery Mobile... Including any jQuery at all seems to break it, e.g. if i leave in only the reference to jquery-1.6.4.min.js it won't work either. Or one of my custom js files for that matter.
Does anyone know what's going on here? Does it have something to do with placement of the file references? I think I have placed them in the correct order (jQuery first, then jQuery mobile and then my custom js)... It doesn't seem like it never works, I tried this app http://coenraets.org/blog/2011/10/sample-application-with-jquery-mobile-and-phonegap/ and that works fine. It has the script references rather strangely placed at the bottom of the file, just before the closing body tag. But I tried doing that too, and then the jQuery Mobile stuff didn't kick in at all (although I could see the content).
And still, since it works in the 4.3 simulator I don't think there is something really wrong with my code, but then why doesn't it work in 5.0?
This question here on stack overflow seems to suggest that the UIWebView in iOS5 requires external script links to have an actual closing tag rather than simply ending with '/>'.
Try to change the links to:
<script type="text/javascript" src="scripts/jquery-1.6.4.min.js"></script>
Does that change anything?
I'm trying to migrate a Phonegap app wich uses jQuery Mobile to Blackberry. When I start the app, which runs fine on Android and iOS. I see no styles, javascript whatsoever.
I figured, that Blackberry webworks apps use different file paths than iOs and Android. I find this file path thing a bit odd in general.
Like when you use a file path in an HTML file like for <img src="res/img/..."> the normal relative path is fine for Android and iOS. BUT if you specify a file path in JS you need "file:///android_asset/www/res/img" for Android while "res/img/" is fine for iOS. But anyways... what's the case with Blackberry here?
Do external JavaScript and CSS files require something like the following?
<link rel="stylesheet" href="local:///lib/jquerymobile/jquery.mobile.min.css" />
or should it work the normal way by just specifinging the relative path?
Besides that, are there other pitfalls? Like I heard about file naming issues when using "dashes", "underscores", whatsoever.
Would be great if someone with exerience with Phonegap apps for BB could share their experiences.
This is what i have:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, height=device-height,
initial-scale=1.0, 'maximum-scale=1.0, 'minimum-scale=1.0, user-scalable=no" />
<!-- PhoneGAP -->
<script src="json2.js" type="text/javascript"></script>
<script src="phonegap-1.0.0.js" type="text/javascript"></script>
<!-- JQuery Mobile -->
<link rel="stylesheet" href="resources/jquery.mobile-1.0rc1/jquery.mobile-1.0rc1.min.css" />
<script src="resources/jquery-1.6.4.min.js"></script>
<script src="resources/jquery.cookie.js"></script>
<script src="resources/jquery.mobile-1.0rc1/jquery.mobile-1.0rc1.min.js"></script>
That´s the order that works, check the src attribs to know where you must copy the jqm library.
Good luck!
We've got an ipad web app that needs all the screen real estate it can get. The plan is to use the "add to home screen" functionality once the app is done. However, we've run into a major issue when launching the app via the home screen. When using the HTML5 doctype, the page simply seems to render as plain text (none of the stylesheets or javascript files are loaded). Instead, using the XHTML 1.0 Transitional Doctype causes the page to render correctly, but we're using jQuery Mobile, which requires an HTML5 Doctype to work.
I've made attempts to simply use 'full screen' meta tags and such, but they don't seem to work either. This is the current state of our header code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--<!DOCTYPE html>-->
<html lang="en">
<head runat="server">
<meta charset="utf-8" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no, minimum-scale=1.0, maximum-scale=1.0" />
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
<title>PAGE TITLE</title>
<link href="favicon.png" rel="icon" type="image/png" />
<link rel="stylesheet" href="http://code.jquery.com/mobile/1.0a4/jquery.mobile-1.0a4.min.css" />
<!-- cut other stylesheets and javascript files being loaded -->
<link rel="stylesheet" href="/Vertex.Web/Content/style/tablet/tablet.css" type="text/css" media="all" />
From the research I've done, it sounds like the ipad uses a web.app instead of safarimobile.app when it launches from the home screen. I'm wondering if this is at least part of the problem. One other thought is that the ipad is trying to use a local cache when launching from the home screen, and it's just not liking the relative paths or external URLs when loading stylesheets and javascript.
Fun fact: using both Doctypes in the page will cause correct rendering the first time we open up the page from the home screen, but further attempts will fail due to a parse error (which is expected, since it's a terrible, terrible solution)
Try to add a manifest file, read more here
https://developer.apple.com/library/archive/documentation/iPhone/Conceptual/SafariJSDatabaseGuide/OfflineApplicationCache/OfflineApplicationCache.html