Created attachment 703650 [details]
Samsung Galaxy S3, Firefox 18
Websites pinned with Firefox for Android show up on the homescreen with the default bookmark icon. This is different than websites pinned with the default android Browser, which show up on the appropriate icon for the website (see picture).
Is this a bug or by design? Please feel free to contact me with any questions or comments. Thanks!!
The website tested is: http://m.bbc.co.uk/weather/2643743
Issue reported on SUMO forums: https://support.mozilla.org/en-US/questions/947314
I can confirm this issue (originally reported by me on SUMO).
Samsung Galaxy S3, Firefox 18
I think it may be to do with websites that do not have a favicon. In firefox pinning websites where there is a favicon results in a site specific logo on the icon (although pixelated on the S3 screen). But websites without a favicon just get a generic bookmark symbol.
I don't know how the stock android browser picks up the symbols it uses for sites without favicons.
I have done some more research and I think this comes down to the use of an icon called 'apple-touch-icon.png'.
This is the one for the bbc: http://www.bbc.co.uk/apple-touch-icon.png
It seems that apple mobile devices will automatically scan the root directory of a website for an image with that name and will use it as a shortcut image. Alternatively the website builder can add some html to their web page so that android will also pick up the image.
The BBC weather mobile site has not inserted this code for android devices. However I am guessing that a recent update in android has added the ability to scan the root directory like apple devices do, without html.
See here for more info: http://www.zen.co.uk/blog/setting-a-home-screen-icon-for-your-website-on-ios-and-android-devices/
It looks to me like the firefox browser on android isn't doing this scan and so is not picking up the 'apple-touch-icon.png'.
Renaming summary because we just introduced a different concept of 'pinning'
This was discussed before in bug 715263 but I believe there were complications. The support was removed from the final patch in that bug.
(In reply to Aaron Train [:aaronmt] from comment #4)
> This was discussed before in bug 715263 but I believe there were
> complications. The support was removed from the final patch in that bug.
I don't think bug 715263 is talking about the same issue. There they are suggesting using apple-touch-icon.png images instead of favicons in the awesome screen and url bar. It looks like it was rejected because apple-touch-icon.png images are designed as home screen icons not favicon replacements.
This current issue is that apple-touch-icon.png images are not picked up as home screen icons when bookmarks are added to the home screen.
I don't mind doing this, but we need a UX/Product call.
I think when we've talked about it before, some of the arguments were that these icons are designed specifically for the iphone. In fact, some of them rely on the iPhone to do some special processing before they're shown. We can try to replicate that same processing without much work I think, but they may still not fit in well on Android devices? That doesn't bother me really.
There are also some concerns about basically "endorsing" a proprietary api on the web. We support high res icons if the sites provide them using the sizes attribute on the favicon links. We need to extend that to formats that support multiple sizes in one image (bug 419588). It hasn't caught on wildly, I assume because webkit browsers haven't implemented support for it, which is why I'm fine re-evaluating this.
We also support a nice method of providing icons for webapps, and wanted to create some delineation between those and "shortcuts" for users. Right now we do that by providing a background behind the shortcut icons.
Thanks Wesley Johnston!
Yes, I completely understand the issue of "endorsing" the proprietary api. Particularly as Apple seem to have ignored a less verbose standard that was already in place - <link rel=icon>
On the other side is that it would be nice to be able to give the same good experience to users as on the stock android browser.
It is a fine line to walk. I'll be interested to see what decision is made.
(In reply to Wesley Johnston (:wesj) from comment #6)
> I don't mind doing this, but we need a UX/Product call.
> I think when we've talked about it before, some of the arguments were that
> these icons are designed specifically for the iphone. In fact, some of them
> rely on the iPhone to do some special processing before they're shown. We
> can try to replicate that same processing without much work I think, but
> they may still not fit in well on Android devices? That doesn't bother me
I think if we have big icons at our disposal, we should just use them.