Last Comment Bug 832077 - Websites added to Android home-screen have default bookmark icon instead of the actual icon of the website
: Websites added to Android home-screen have default bookmark icon instead of t...
Status: NEW
:
Product: Firefox for Android
Classification: Client Software
Component: General (show other bugs)
: 18 Branch
: ARM Android
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Sebastian Kaspari (:sebastian)
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-17 15:55 PST by Ralph Daub [:rdaub]
Modified: 2016-11-11 02:55 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Pinned websites (1.38 MB, image/png)
2013-01-17 15:55 PST, Ralph Daub [:rdaub]
no flags Details

Description Ralph Daub [:rdaub] 2013-01-17 15:55:33 PST
Created attachment 703650 [details]
Pinned websites

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
Comment 1 EddyCarr 2013-01-18 01:43:23 PST
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.
Comment 2 EddyCarr 2013-01-18 08:00:23 PST
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'.
Comment 3 Aaron Train [:aaronmt] 2013-01-18 08:05:39 PST
Renaming summary because we just introduced a different concept of 'pinning'
Comment 4 Aaron Train [:aaronmt] 2013-01-18 08:09:02 PST
This was discussed before in bug 715263 but I believe there were complications. The support was removed from the final patch in that bug.
Comment 5 EddyCarr 2013-01-18 09:06:01 PST
(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.
Comment 6 Wesley Johnston (:wesj) 2013-01-18 09:29:51 PST
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.
Comment 7 EddyCarr 2013-01-18 09:55:49 PST
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.
Comment 8 Ian Barlow (:ibarlow) 2013-03-06 08:11:23 PST
(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
> really.

I think if we have big icons at our disposal, we should just use them.

Note You need to log in before you can comment on or make changes to this bug.