Closed Bug 921014 Opened 11 years ago Closed 10 years ago

[BrowserAPI] Support link rel="apple-touch-icon" in mozbrowsericonchange event

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla34

People

(Reporter: gasolin, Assigned: daleharvey)

References

Details

(Whiteboard: [flatfish][TCP=polish][systemsfe])

Attachments

(2 files, 2 obsolete files)

link-rel-icon-alexa-500.txt
79.75 KB, text/plain
Details
921014.patch
5.55 KB, patch
fabrice
: review+
Details | Diff | Splinter Review
We'd looking for some way to get better bookmark icons on tablet homescreen. See discussion here https://groups.google.com/forum/#!topic/mozilla.dev.gaia/Bi2-ufWd75A Apple has addressed this issue. And Android also support following syntax since 2.2. The question is, should we follow the convention and support in Firefox OS, or start working on something for standard? (digest from https://developer.apple.com/library/ios/documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html ) """ You can place an icon file in PNG format in the root document folder called `apple-touch-icon.png` or `apple-touch-icon-precomposed.png` with following syntax: <link rel="apple-touch-icon" href="touch-icon-iphone.png" /> then users are able to add webpage link to the Home screen with better icon presentation. """ (Currently Firefox OS browser can save bookmark to homescreen, with a default icon background and a web site's favicon onto it. It works fine on current small sized phone, but looks not pretty in bigger size(tablet)/higher resolution(WVGA) devices since the limit of favicon's resolution. )
Blocks: flatfish
blocking-b2g: --- → 1.3?
Blocks: 897900
Gecko bug indeed.
Component: Gaia::Browser → General
Summary: [Browser] Support link rel="apple-touch-icon" for homescreen bookmark → [BrowserAPI] Support link rel="apple-touch-icon" in mozbrowsericonchange event
Assignee: nobody → alive
Attached patch 921014.patch (obsolete) — — Splinter Review
Patch v1: Support apple-touch-icon and apple-touch-icon-precomposed in mozbrowsericonchange.
Attachment #812549 - Flags: review?(fabrice)
Attachment #812549 - Attachment is patch: true
Attachment #812549 - Attachment mime type: text/html → text/plain
(In reply to Alive Kuo [:alive] from comment #2) > Created attachment 812549 [details] [diff] [review] > 921014.patch > > Patch v1: Support apple-touch-icon and apple-touch-icon-precomposed in > mozbrowsericonchange. This feels like this needs discussion on whether we want to do this first before we implement this. This implements a non-standard feature only apple supports, which might not be a good idea for the web.
Comment on attachment 812549 [details] [diff] [review] 921014.patch Review of attachment 812549 [details] [diff] [review]: ----------------------------------------------------------------- I'm pretty sure we don't want that. Sites that serve this kind of icons are very likely to also expect a webkit browser and serve us content that won't be ideal.
Attachment #812549 - Flags: review?(fabrice) → review-
Closing this as a WONTFIX per comment 4 - we should not support webkit-specific properties in gecko.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
First of all there is already a draft and a recommendation for this. http://www.w3.org/html/wg/drafts/html/master/links.html#rel-icon Copy of the spec example as of today. <!DOCTYPE HTML> <html> <head> <title>lsForums — Inbox</title> <link rel=icon href=favicon.png sizes="16x16" type="image/png"> <link rel=icon href=windows.ico sizes="32x32 48x48" type="image/vnd.microsoft.icon"> <link rel=icon href=mac.icns sizes="128x128 512x512 8192x8192 32768x32768"> <link rel=icon href=iphone.png sizes="57x57" type="image/png"> <link rel=icon href=gnome.svg sizes="any" type="image/svg+xml"> <link rel=stylesheet href=lsforums.css> <script src=lsforums.js></script> <meta name=application-name content="lsForums"> </head> <body> What are the Web sites where it is currently failing? Do we support already the combination rel icon with the "sizes" attribute? I would not be in favor of supporting apple rel value. Voting for a WONTFIX.
(In reply to Karl Dubost :karlcow from comment #6) > Do we support already the combination rel icon with the "sizes" attribute? Yes.
Are we confident a lot of content already uses the new format? If not, can we add a fallback path? Is that worth it? Will that give us a lot of existing icons? Please do some quick evaluation and close this if its not worth it, or land something if it is.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to Andreas Gal :gal from comment #8) > Are we confident a lot of content already uses the new format? If not, can > we add a fallback path? Is that worth it? Will that give us a lot of > existing icons? Please do some quick evaluation and close this if its not > worth it, or land something if it is. We support the usual rel=icon (widely used), with the optional "sizes" (less widely used I think, but nice to have). I only object to add apple-specific roles.
(In reply to Andreas Gal :gal from comment #8) > Are we confident a lot of content already uses the new format? If not, can > we add a fallback path? Is that worth it? Will that give us a lot of > existing icons? Please do some quick evaluation and close this if its not > worth it, or land something if it is. So there is always a business decision here with consequences. 1. No support. We might end up in interop issues where some sites do not provide the right way of doing it, but that would mean they would also fail on other platforms which are not iOS. But before making that decision we need to base it on real data. How much is this an issue currently. How many sites have a bad icon because because of those giving only this value. 2. Supporting a fallback. Here we enter in another game which further pushes the WebKit footprint. Basically by providing a fallback, we have two consequences: 2.1 Bugs don't get reported because people do not see it (except if there's an automatic call home when the fallback kicks in, then privacy issues, yada yada.) 2.2 Fixes are harder to explain to the Web developer because "Hey it is working. Why do you bother me to modify a code which is working?". The site never gets fixed and the fallback stays in the code for a loooong time. A fallback is really useful when it creates a real interoperability issues aka a browser behavior breaking totally the user experience to the point where it is not functional.
Implement the Web, not the specs. If the Web overwhelmingly uses apple's ****, we don't have much of a choice here. This is a bit like the UA issue. With our current market share sitting this out may not be an option. Optimize for user experience here. I am all for avoid the fallback, if it doesn't interfere with a good user experience. If more than a few outliers don't support anything but the apple ****, I think our hands are tied.
(In reply to Andreas Gal :gal from comment #11) > Implement the Web, not the specs. If the Web overwhelmingly uses apple's > crap, we don't have much of a choice here. I think there are two primary considerations for this argument. 1. Is what Andreas listed above - the case where the Apple way is already the defacto standard. 2. What benefit do we get by including this support. Does this change only impact a small number of sites? Is the functionality critical or really just a nice to have?
(In reply to Andreas Gal :gal from comment #11) > Implement the Web, not the specs. If the Web overwhelmingly uses apple's > crap, we don't have much of a choice here. I replied to that already in comment #10 > But before making that decision we need to base it on real data. How much is this an issue currently. How many sites have a bad icon because because of those giving only this value. Which is the point 2. of comment #12 by lawrence. We do not disagree. My first question in comment #6 was "What are the Web sites where it is currently failing?"
> > Which is the point 2. of comment #12 by lawrence. We do not disagree. My > first question in comment #6 was "What are the Web sites where it is > currently failing?" I am sure we can provide such a list of example sites. I am not sure of the value of that. I think what we want is a quick analysis of some relevant top sites to understand the ballpark problem. Considering Apple's market share and weight with web developers, my gut feeling is telling me that we can't ignore this. I am very easily swayed with data.
(In reply to Lawrence Mandel [:lmandel] from comment #12) > I think there are two primary considerations for this argument. > 1. Is what Andreas listed above - the case where the Apple way is already > the defacto standard. Sadly I think the evidence suggests that the cowpath has been bulldozed by iOS. See http://i.imgur.com/7VcclAW.png (Screenshot from "Programming the Mobile Web" book). Opera's new Coast browser recommends rel="icon" @sizes, but will consume the Windows 8 and iOS icons if they exist so they can have pretty icons. [1] I think an approach like this is pragmatic--look for the standard recommendation, but failing that grab the high-res images that are there (even if they have the word apple in them) to be compatible with deployed content. (For even more fun, an article by Mathias Bynens [2] states that iOS now looks for /.well-known/apple-touch-icon.png, even without the rel attribute.) [1] http://coastbyopera.com/developer [2] http://mathiasbynens.be/notes/touch-icons
Just for the record, I'm in the process of running a (quick dirty) script on top 500 Alexa to test link rel. I'll test after the /.well-known/ space. :) Titanic fight and horrors. Movie at 8pm! Bring the pop corn.
It might be worth talking to Apple about this. They might at this point regret their poor choices of the past as well and we can jointly agree on a path forward out of this insanity. We will have to start with a fallback most likely, but we can probably back out of this over time.
(In reply to comment #17) > It might be worth talking to Apple about this. They might at this point regret > their poor choices of the past as well and we can jointly agree on a path > forward out of this insanity. We will have to start with a fallback most > likely, but we can probably back out of this over time. It may also be a good idea to talk to the Blink folks as well to see if they're going to keep support for this.
OK. Let's see on a top 500 Alexa list. It might need a fresher list, I took one I had handy. Context: * followed the HTTP redirections (not the JS ones) * used User-Agent:'Mozilla/5.0 (Tablet; rv:18.1) Gecko/18.1 Firefox/18.1' Results (numbers are Web sites) * 32 with link rel="apple-touch-icon-precomposed" (1 or more) including 20 had no sizes attributes at all 4 had only links with sizes attributes 8 had a combination of sizes and no sizes * 68 with link rel="apple-touch-icon" including 60 had no sizes attributes 16 sites had size attributes * only 1 site was doubling rel="apple-touch-icon-precomposed" sizes= rel="apple-touch-icon" sizes= * 217 with link rel="shortcut icon" * 71 with link rel="icon" * only "2" sites were using rel="icon" sizes="" but with small sizes (wordpress) =18,wordpress.com========================================== <link rel="shortcut icon" type="image/vnd.microsoft.icon" href="http://s1.wp.com/i/favicon-stacked.ico?m=1311976025g" sizes="16x16 32x32 48x48"> <link rel="shortcut icon" type="image/x-icon" href="http://s2.wp.com/i/favicon.ico?m=1311976025g" sizes="16x16"> <link rel="icon" type="image/x-icon" href="http://s2.wp.com/i/favicon.ico?m=1311976025g" sizes="16x16"> =189,files.wordpress.com========================================== <link rel="shortcut icon" type="image/vnd.microsoft.icon" href="http://s1.wp.com/i/favicon-stacked.ico?m=1311976025g" sizes="16x16 32x32 48x48"> <link rel="shortcut icon" type="image/x-icon" href="http://s2.wp.com/i/favicon.ico?m=1311976025g" sizes="16x16"> <link rel="icon" type="image/x-icon" href="http://s2.wp.com/i/favicon.ico?m=1311976025g" sizes="16x16"> one with big size =116,reddit.com========================================== <link rel='icon' href="http://www.redditstatic.com/icon.png" sizes="256x256" type="image/png" /> The three of them had the apple-touch. So basically no sites at all (in the one tested were sending us) link rel="icon" sizes="" Another sad story of interoperability and namespace pollution. **Caveats in these results**: Many sites do redirection based on JavaScript. We are not detecting those. Given these results I will change my mind (against my heart) and it's worth thinking about implementing the patch at least as a backup waiting for a better time when anyone do things properly on their sites.
Based on your data, we support the 217 rel="shortcut icon" *and* the 71 with rel="icon".
(In reply to Fabrice Desré [:fabrice] from comment #20) > Based on your data, we support the 217 rel="shortcut icon" *and* the 71 with > rel="icon". Yes. But it's not the issue at stake ;) The issue is "We'd looking for some way to get better bookmark icons on tablet homescreen." The shortcut icon and most icon are icons made for bookmarks, which are indeed crappy once they are added to the homescreen. Look at the attachment file :)
Whiteboard: [Flatfish only]
this bug wont block tablet developer release, changed to ---
blocking-b2g: 1.3? → ---
This is biting on Android, too: Bug 958399 is an example in the wild. It's particularly visible on Android because all other Android browsers support the apple-prefixed links, and we're the monkeys stuck putting grey globe icons on your home screen because some photo commerce site was designed for iPhones. I'm inclined to agree with Andreas in Comment 11. So: what can we do to get this done and shipped in Gecko?
Blocks: 958399
OS: Gonk (Firefox OS) → All
Hardware: Other → All
I'd rather think `apple-touch-icon` is a credit as apple's contribution to mobile web. Just like why every browser need add `Gecko` in their User-agent string.
One of the reasons Firefox for Android does not yet use "apple-touch-icon[-precomposed]" is that the style of the icons is really designed for iOS. When displaying the icons on Android, they can look very out of place. So much so that we decided to ignore the icons for now. Android itself support many DPIs and has a variety of preferred home screen icon sizes. We have been holding out for better <link re="[shortcut] icon" size="..."> support. We also recently added support for pulling the largest image from an .ICO file. Make sure your ICO code is not pulling out the first image, which is usually 16x16.
(In reply to Karl Dubost :karlcow from comment #19) > =18,wordpress.com========================================== > <link rel="shortcut icon" type="image/vnd.microsoft.icon" > href="http://s1.wp.com/i/favicon-stacked.ico?m=1311976025g" sizes="16x16 > 32x32 48x48"> > <link rel="shortcut icon" type="image/x-icon" > href="http://s2.wp.com/i/favicon.ico?m=1311976025g" sizes="16x16"> > <link rel="icon" type="image/x-icon" > href="http://s2.wp.com/i/favicon.ico?m=1311976025g" sizes="16x16"> > > =189,files.wordpress.com========================================== > <link rel="shortcut icon" type="image/vnd.microsoft.icon" > href="http://s1.wp.com/i/favicon-stacked.ico?m=1311976025g" sizes="16x16 > 32x32 48x48"> > So basically no sites at all (in the one tested were sending us) > > link rel="icon" sizes="" > > Another sad story of interoperability and namespace pollution. Why is "shortcut icon" different than "icon" ? As long as "icon" is in the rel we're fine, right?
(In reply to Mark Finkle (:mfinkle) from comment #26) > Why is "shortcut icon" different than "icon" ? As long as "icon" is in the > rel we're fine, right? Kinda academic, I suspect -- my sample size of 1 suggests that rel="icon" -- with or without shortcut -- simply isn't present at all for iOS-tested webapps. apple-touch-icon only. (And why would they bother? All iOS and Android browsers apart from Firefox support apple-touch-icon.)
(In reply to Mark Finkle (:mfinkle) from comment #26) > Why is "shortcut icon" different than "icon" ? As long as "icon" is in the > rel we're fine, right? Short answer: yes Long answer: * http://mathiasbynens.be/notes/rel-shortcut-icon * http://mathiasbynens.be/notes/touch-icons
Whiteboard: [Flatfish only] → [flatfish]
Is there any progress on this? (In reply to Mark Finkle (:mfinkle) from comment #25) > One of the reasons Firefox for Android does not yet use > "apple-touch-icon[-precomposed]" is that the style of the icons is really > designed for iOS. When displaying the icons on Android, they can look very > out of place. So much so that we decided to ignore the icons for now. Chrome seems to use apple-touch-icon (or some other icon that looks better than the favicon Firefox uses) on sites like here.com
See Also: → 1041482
http://junk.arandomurl.com/Screenshot_2014-07-22-00-33-53.png is a screenshot I took from my android phone, the top apps are saved to homescreen from chrome, the buttom apps are saved to homescreen from firefox > Based on your data, we support the 217 rel="shortcut icon" *and* the 71 with rel="icon". Those are all favicons generally at a 16x16 resolution. If we dont land this then there will be pretty much 0 impact on the work done in https://bugzilla.mozilla.org/show_bug.cgi?id=1041482 to provide higher resolution icons to fxos users. Alive, can you rebase this patch? happy to take it over if you fancy, once its rebase then can see if we can convince fabrice for an r+ :)
Flags: needinfo?(alive)
Would it be possible for the patch to send a warning in the console? I could draft a message and possibly a link to the right resource recommending the best practice. Maybe Mathias Bynens has more opinions on what is below. Bugs in webkit related to icons https://bugs.webkit.org/show_bug.cgi?id=125775 sizes attributes https://bugs.webkit.org/show_bug.cgi?id=104585 404 for the icons https://bugs.webkit.org/show_bug.cgi?id=120473 apple-touch-icon-precomposed href not honored https://bugs.webkit.org/show_bug.cgi?id=68861 Support for multiple <link rel="icon"> favicon elements It's the moment where I think that Mozilla should almost submit a patch on webkit project to improve its Web standards support and give a chance to the standard. According to http://mathiasbynens.be/notes/touch-icons Chrome 31+ supports the right syntax. BUT they also support the apple-touch-icon > "If no such HTML is found, Chrome for Android falls back to the Apple touch icons instead." It means that basically, Web designers/testers will not see the effect of not using the standard. That's always the danger of fallback, it often pushed the already deployed. To note also that in the past they were doing prefetch in the blink like iOS is doing http://src.chromium.org/viewvc/blink?view=revision&revision=154413
Flags: needinfo?(mathias)
(In reply to Dale Harvey (:daleharvey) from comment #30) > http://junk.arandomurl.com/Screenshot_2014-07-22-00-33-53.png > > is a screenshot I took from my android phone, the top apps are saved to > homescreen from chrome, the buttom apps are saved to homescreen from firefox > > > Based on your data, we support the 217 rel="shortcut icon" *and* the 71 with rel="icon". > > Those are all favicons generally at a 16x16 resolution. > > If we dont land this then there will be pretty much 0 impact on the work > done in https://bugzilla.mozilla.org/show_bug.cgi?id=1041482 to provide > higher resolution icons to fxos users. > > Alive, can you rebase this patch? happy to take it over if you fancy, once > its rebase then can see if we can convince fabrice for an r+ :) I will rebase it within this week. Will let you know if I am occupied.
Flags: needinfo?(alive)
(In reply to Karl Dubost :karlcow from comment #31) > According to http://mathiasbynens.be/notes/touch-icons > Chrome 31+ supports the right syntax. BUT they also support the > apple-touch-icon > > "If no such HTML is found, Chrome for Android falls back to the Apple touch icons instead." > It means that basically, Web designers/testers will not see the effect of > not using the standard. That's always the danger of fallback, it often > pushed the already deployed. Google’s intention is to drop support for the proprietary Apple syntax at some point. See https://developer.chrome.com/multidevice/android/installtohomescreen#icon: > Caution:The 196px image format is recommended. The last two formats (apple-touch-*) > are deprecated, and will be supported only for a short time.
Flags: needinfo?(mathias)
FYI, Amazon doesn't send apple-touch-icon by default. They sniff for the device to do so. So even with this support, we might still have some compatibility problems. Projects like http://realfavicongenerator.net already support the sizes attribute. Shouldn't we send a "intent-to-implement/ship" email for this kind of thing?
(In reply to Mathias Bynens from comment #33) > > Google’s intention is to drop support for the proprietary Apple syntax at > some point. See > https://developer.chrome.com/multidevice/android/installtohomescreen#icon: I've tried the patch from Alive against current m-c (its a two lines patch) and must say that gives incredible results. After seeing this comment and the documentation, I'm a bit sad and change mind to not to use it, despite that the work we are doing won't have a great impact.
I think `a short time` statement in this webpage is debatable(at least not happened in chrome canary) and there's no sign that top sites are adopting the `preferred` icon size way, which mean `the short time` not likely happened in half a year. Since its a low hanging fruit(patches are there), it's worth to support the de facto convention (apple-icon) and the standard way(icon size) than keep our bookmark icon ugly (and do nothing) for high resolution devices, which really hurts the user experience.
(In reply to Anthony Ricaud (:rik) from comment #34) > Shouldn't we send a "intent-to-implement/ship" email for this kind of thing? This definitely deserves an intent email. Alive, would you please send one, so that we can disucss this on dev-platform? Thank you!
Flags: needinfo?(alive)
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #37) > (In reply to Anthony Ricaud (:rik) from comment #34) > > Shouldn't we send a "intent-to-implement/ship" email for this kind of thing? > > This definitely deserves an intent email. Alive, would you please send one, > so that we can disucss this on dev-platform? Thank you! Yes, not yet in dev-platform maillist though. Ongoing.
Flags: needinfo?(alive)
Please don't ever do work on anything that's part of Gecko in Firefox OS::General.
Component: General → DOM
Product: Firefox OS → Core
(In reply to Mike Taylor [:miketaylr] from comment #15) > (For even more fun, an article by Mathias Bynens [2] states that iOS now > looks for /.well-known/apple-touch-icon.png, even without the rel attribute.) > > [2] http://mathiasbynens.be/notes/touch-icons I’m confused – I never wrote such a thing (nor did I research it), and can’t find any mention of `.well-known` on that page. Can you clarify?
Whiteboard: [flatfish] → [flatfish][TCP=polish]
Mathias I think Mike meant the issue with "well known location" cluttering the namespace of a Web site (such as favicon, robots.txt, p3p, etc.) > If no icons are specified in the HTML, iOS Safari will > search the website’s root directory for icons with the > apple-touch-icon or apple-touch-icon-precomposed prefix. but it's indeed confusing because /.well-known/ is an RFC 5785 which has been created to address this kind of issues. http://tools.ietf.org/html/rfc5785
Dale, apparently now this issue goes a little uncontrollable. Since this blocks your work, feel free to take then finish it and fight for it if you are in favor.
Flags: needinfo?(dale)
Assignee: alive → dale
Flags: needinfo?(dale)
Attached patch 921014.patch (obsolete) — — Splinter Review
Rebased Alive's patch and added the rel="" information into the event. The arguments for supporting apple-touch-icon. We have support for the standard rel='icon', it will take preference over the non standard, documentation pushes the standard and other vendors are supporting this temporarily while informing developers to use the standard method. It is a huge improvement in how well the user experiences web content, we have improvements to 1/5th of content as opposed to the 1/250th we do with the support for the standard only. The improvement is large on mobile devices, I expect on higher resolution devices like the tablet the difference will be even larger. I will be happy to open a bug to track and remove this support when the adoption of the standard is at least close to parity with support for apple-touch-icon. And as Andreas said > Implement the Web, not the specs. If the Web overwhelmingly uses apple's crap, we don't have much of a choice here. This is a bit like the UA issue. With our current market share sitting this out may not be an option. Optimize for user experience here. I am all for avoid the fallback, if it doesn't interfere with a good user experience. If more than a few outliers don't support anything but the apple crap, I think our hands are tied.
Attachment #812549 - Attachment is obsolete: true
Attachment #8463384 - Flags: review?(fabrice)
Comment on attachment 8463384 [details] [diff] [review] 921014.patch Review of attachment 8463384 [details] [diff] [review]: ----------------------------------------------------------------- I don't think we want to send back to gaia the rel type. Everything should just look as if it was a proper standard link. ::: dom/browser-element/BrowserElementChildPreload.js @@ +474,5 @@ > debug('Got iconchanged: (' + e.target.href + ')'); > let icon = { href: e.target.href }; > + this._maybeCopyAttribute(e.target, icon, 'sizes'); > + this._maybeCopyAttribute(e.target, icon, 'rel'); > + this._maybeCopyAttribute(e.target, icon, 'type'); why do you need rel and type? @@ +516,5 @@ > > let handlers = { > + 'icon': this._iconChangedHandler.bind(this), > + 'apple-touch-icon': this._iconChangedHandler.bind(this), > + 'apple-touch-icon-precomposed': this._iconChangedHandler.bind(this), remove the -precomposed one. It's not even in https://developer.apple.com/library/ios/documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html anymore.
Attachment #8463384 - Flags: review?(fabrice)
Karl, Mike: do you think the webcompat team can reach out to web properties that have the apple variant but not the standard one to add the right <link> ?
Flags: needinfo?(miket)
Flags: needinfo?(kdubost)
> why do you need rel and type? I added |rel| so we could specifically favour standard rel="icon"'s over rel="apple-touch-icon", currently we have no way to distinguish them. |type| I added for completeness and I figured it may help with detecting when we want to extract a single icon from a bundle, although not a lot of people actually specify the type Should I remove rel or both? > remove the -precomposed one. Will do
Attached patch 921014.patch — — Splinter Review
I removed rel and type, if we do end up needing type then no need to conflate it with this patch, we can add it later Removed -precomposed
Attachment #8463384 - Attachment is obsolete: true
Attachment #8463482 - Flags: review?(fabrice)
(In reply to Mathias Bynens from comment #40) > (In reply to Mike Taylor [:miketaylr] from comment #15) > > (For even more fun, an article by Mathias Bynens [2] states that iOS now > > looks for /.well-known/apple-touch-icon.png, even without the rel attribute.) > > > > [2] http://mathiasbynens.be/notes/touch-icons > > I’m confused – I never wrote such a thing (nor did I research it), and can’t > find any mention of `.well-known` on that page. Can you clarify? FTA: "If no icons are specified in the HTML, iOS Safari will search the website’s root directory for icons with the apple-touch-icon or apple-touch-icon-precomposed prefix." That's all. :) (In reply to Fabrice Desré [:fabrice] from comment #45) > Karl, Mike: do you think the webcompat team can reach out to web properties > that have the apple variant but not the standard one to add the right <link> > ? I think so yes. As long as we're happy and patient enough for this kind of long tail solution (since we can't control properties priorities or willingness to do anything). http://webcompat.com/ might be a good place to report these types of issues.
(In reply to Mike Taylor [:miketaylr] from comment #49) > (In reply to Fabrice Desré [:fabrice] from comment #45) > > Karl, Mike: do you think the webcompat team can reach out to web properties > > that have the apple variant but not the standard one to add the right <link> > > ? > > I think so yes. As long as we're happy and patient enough for this kind of > long tail solution (since we can't control properties priorities or > willingness to do anything). http://webcompat.com/ might be a good place to > report these types of issues. Not in bugzilla?
(In reply to Fabrice Desré [:fabrice] from comment #50) > Not in bugzilla? Bugzilla is also OK in the Tech Evangelism :: Mobile component. If in theory Chrome Mobile drops support for the apple variants webcompat.com would be a good place to collaborate on that kind of outreach. But either is fine by me.
(In reply to comment #51) > (In reply to Fabrice Desré [:fabrice] from comment #50) > > Not in bugzilla? > > Bugzilla is also OK in the Tech Evangelism :: Mobile component. If in theory > Chrome Mobile drops support for the apple variants webcompat.com would be a > good place to collaborate on that kind of outreach. But either is fine by me. Do we have any indication from Chrome wanting to drop this soon (other than the note about this being "deprecated" in their docs)?
1. Cool to have the log message in Gaia, it will help us to advertise what is the issue when we are contacting people. 2. Would it be possible to have the lack/presence of the standard way with 'sizes' in Metrics. So we can measure to which extent with real organic data how it is (would be) broken for Mozilla users. In that way we could also have an easier outreach by knowing the main sites we should address in that effort.
Flags: needinfo?(kdubost)
Important message to read before finalizing our implementation http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jul/0174.html > Chrome 30 dropped support[1] for fetching apple-touch-icon-* from well > known URLs, since the 404 pages that are usually returned were consuming > 3-4% of all mobile bandwidth usage[2]. We're unlikely to reverse that. > > We still support apple-touch-icon-* via link rel under some circumstances > (e.g. for add to homescreen), but they're deprecated[3], since we'd like > authors to use the standard for this, i.e.: > > <link rel="shortcut icon" sizes="128x128" href="/favicon.png"> > > (or even good old: > > <link rel="shortcut icon" href="/favicon.ico"> > > with multiple resolutions in the .ico file for compatibility with IE<11). > > [1]: https://code.google.com/p/chromium/issues/detail?id=259681 > [2]: https://bugs.webkit.org/show_bug.cgi?id=104585 > [3]: https://code.google.com/p/chromium/issues/detail?id=296962
(In reply to comment #54) > Important message to read before finalizing our implementation > http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jul/0174.html > > > Chrome 30 dropped support[1] for fetching apple-touch-icon-* from well > > known URLs, since the 404 pages that are usually returned were consuming > > 3-4% of all mobile bandwidth usage[2]. We're unlikely to reverse that. I thought this is *only* limited to <link rel=apple-touch-icon> elements. Am I missing something?
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #55) > I thought this is *only* limited to <link rel=apple-touch-icon> elements. > Am I missing something? Comment 49: --- FTA: "If no icons are specified in the HTML, iOS Safari will search the website’s root directory for icons with the apple-touch-icon or apple-touch-icon-precomposed prefix." That's all. :) ---
Comment on attachment 8463482 [details] [diff] [review] 921014.patch Review of attachment 8463482 [details] [diff] [review]: ----------------------------------------------------------------- r=me ::: dom/browser-element/BrowserElementChildPreload.js @@ +480,5 @@ > + _maybeCopyAttribute: function(src, target, attribute) { > + if (src.getAttribute(attribute)) { > + target[attribute] = src.getAttribute(attribute); > + } > + }, nit: move this function before the first use in _iconChangedHandler
Attachment #8463482 - Flags: review?(fabrice) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/8f4b3b59f1a4
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → FIXED
In which bug do we track the Web console event that the usage of apple-touch link happened? Should there be a dependency so we do not forget it ;)
Flags: needinfo?(fabrice)
That seems like it would be tricky to implement, developers need to implement apple-touch-icon to be supported on other platforms, its not a case of them using a deprecated API where they are certainly doing the wrong thing, if we warn whenever we see an apple-touch-icon then we will be warning users who also perfectly implement the standard (which would be confusing) We can add a bunch of extra stuff to the api to warn only when we use the apple-touch-icon, but changing what is technically a web api (mozbrowser) to be able to do that doesnt seem like the best approach to standards. It seems to me like this should be fixed via documentation and evangelism.
(In reply to Dale Harvey (:daleharvey) from comment #61) > That seems like it would be tricky to implement, developers need to > implement apple-touch-icon to be supported on other platforms, its not a > case of them using a deprecated API where they are certainly doing the wrong > thing, if we warn whenever we see an apple-touch-icon then we will be > warning users who also perfectly implement the standard (which would be > confusing) > > We can add a bunch of extra stuff to the api to warn only when we use the > apple-touch-icon, but changing what is technically a web api (mozbrowser) to > be able to do that doesnt seem like the best approach to standards. > > It seems to me like this should be fixed via documentation and evangelism. Dale, what we need is gaia to emit a warning in the console when it has selected an icon that was an apple-touch-icon and not a standard one. That will let us know which sites the webcompat team needs to talk to.
Flags: needinfo?(fabrice)
Blocks: 1045934
Blocks: 1045974
Target Milestone: --- → mozilla34
For what it's worth, we will document this change but include a note reminding people to please support the real standard for future compatibility etc.
Blocks: 1059470
(In reply to Fabrice Desré [:fabrice] from comment #44) > remove the -precomposed one. It's not even in > https://developer.apple.com/library/ios/documentation/AppleApplications/ > Reference/SafariWebContent/ConfiguringWebApplications/ > ConfiguringWebApplications.html anymore. Just a note to be more exact. In https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/MobileHIG.pdf (heavy PDF), page 224 on 227 > You can prevent the addition of any effects by naming your icon apple-touch-icon-precomposed.png Also in the one cited above, it is said: > Note: Safari on iOS 7 doesn’t add effects to icons. Older versions > of Safari will not add effects for icon files named with the > -precomposed.png suffix. See “First Steps: Identifying Your App in > iTunes Connect” for details. People using iOS 7 don't need at all. *Now*, I bet Apple will not remove the support in iOS, because of sites like Facebook Bug 1059470 Comment #9
Whiteboard: [flatfish][TCP=polish] → [flatfish][TCP=polish][systemsfe]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: