1074937 - Change the default favicon from an empty dashed-box to a globe.

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[u428464]

Currently when the first item in the awesomebar is an autocompleted result or an arbitrary URL (visit URL) the default dotted favicon is displayed. It isn't very indicative nor very nice visually. Maybe a better favicon could be displayed (for example a sheet of paper that would maybe better represent that a webpage will be loaded).

Comment 1

[Marco Bonardo [:mak]]

I agree, the default favicon doesn't look nice in this context.

Comment 2

[u428464]

Needinfo'ing UX people to have more info.

Comment 3

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Yes!
Intuitively, I'd go with the globe that we show next to URLs on non-https sites.

Comment 4

[u428464]

Then maybe all instances of the dotted favicon could simply be changed to the globe icon (note that Firefox mobile already use the globe icon as the default favicon).

Comment 5

[u428464]

Can this be added to the unified autocomplete work ?

Comment 6

[Marco Bonardo [:mak]]

yes, it might be part of bug 1181078

Comment 7

[Marco Bonardo [:mak]]

(In reply to Stephen Horlander [:shorlander] (Away until 7/20) from comment #4)
> (In reply to Marco Bonardo [::mak] from comment #3)
> > My second question is, should we keep using the default empty dotted favicon
> > for entries not having a favicon, even if it looks quite bad in this
> > context? (see bug 1074937 for example). Should we rather use the globe icon
> > as suggested here (https://bugzilla.mozilla.org/show_bug.cgi?id=1074937#c3)?
> 
> Yeah, switching to the globe would be nice here. I think the dotted outline
> doesn't work that well in a lot places. Would work better as a transient
> thing while we fetch a favicon or decide there isn't a favicon and switch to
> the globe.

Comment 8

[Bill Maggs (bmaggs)]

Broken favicon display has been a significant problem for a long time not only in the awesome bar but in the Tabs from My Other Devices (sync Tabs). We should make the behavior the same on both, and the sync team supports using a FF globe icon in place of the broken lines (hereafter referred to as the blahvicon), along with an attempt to improve performance of favicon fetch, cache, and display. 

The irony is that the more you use Firefox on more devices and sync them via your Firefox Account, the more blahvicons and the worse the experience will be for the user. This is important because we are planning to raise the synced tabs view to the hamburger menu, which will make the dotted lines much more visible in the primary UI. In discussion with sync engineers it appears that favicon behavior on sync tabs is different than that on the awesome bar, suggesting a different favicon service or use of the service. Consequently, w will make a separate bug for Sync Tabs favicons and link it to this bug.

Comment 9

[Edwin Wong [:edwong]]

do we have a dev or team who's interested in fixing this?

Comment 10

[Tim Taubert [:ttaubert] (inactive)]

It's on the search team's radar as indicated by comment #6 and #7, you should contact them if you think the Awesomebar redesign should move higher on the priority list.

Comment 11

[Edwin Wong [:edwong]]

Attachment: defaultFavicon.svg

:shorelander - please approve. This is the asset found here:
chrome://browser/skin/identity-not-secure.svg

Upon approval, markh or someone on the team will work on the fix described in here:
bug 1202712

Comment 12

[Stephen Horlander [:shorlander]]

(In reply to Edwin Wong [:edwong] from comment #11)
> Created attachment 8661013 [details]
> defaultFavicon.svg
> 
> :shorelander - please approve. This is the asset found here:
> chrome://browser/skin/identity-not-secure.svg
> 
> Upon approval, markh or someone on the team will work on the fix described
> in here:
> bug 1202712

Works for me. The dashed outline works as a temporary placeholder but not so much if we don't ever fill it in.

Comment 13

[Mark Hammond [:markh] [:mhammond]]

I'd like some opinions on the best way to approach this:

* The current favicon is a .png (and matching @2x.png) but the icon we'd like to change it to already exists as .svg. Apart from a number of references in our tree, many addons also reference the .png versions - but it seems a shame to *not* use .svg here. I'm thinking that we could create a new defaultFavicon.svg in the tree and update all our references to point at the .svg, but leave the 2 .png versions around for addons (and leave them as the existing icon to encourage addons to update over time to using the .svg).

* Many theme assets recently changed to use a "shared" directory and a jar.inc.mn file, which is a big improvement! We could make a start on that for the "mozapps" directories (ie, toolkit/themes/[os]/mozapps), starting just with the files being touched in this bug and leave the more general de-duplication to other bugs. Does that sound reasonable, or should I continue to duplicate the files here and leave the "shared" change until everything can be done in one go?

ni? dolske mainly for the "shared" question as he landed the recent theme changes, but opinions from everyone solicited.

Comment 14

[Bill Maggs (bmaggs)]

We could do this for addon makers, but it probably won't do much good unless we do something to let devs know they should move to the svg versions of favicons. Addon devs are pretty notoriously bad at updating their creations. So we could put out a note to Lisa Brewster's team about it, if we are agreed. 

Related question: I wonder how many addons in AMO ask for favicons (as .pngs)?  Seems like it might be hard to find out, but I will ask the Addon team. 

My general reaction: sounds like a reasonable plan.

Comment 15

[Justin Dolske [:Dolske]]

(In reply to Mark Hammond [:markh] from comment #13)

> * Many theme assets recently changed to use a "shared" directory and a
> jar.inc.mn file, which is a big improvement! We could make a start on that
> for the "mozapps" directories (ie, toolkit/themes/[os]/mozapps), starting
> just with the files being touched in this bug and leave the more general
> de-duplication to other bugs. Does that sound reasonable, or should I
> continue to duplicate the files here and leave the "shared" change until
> everything can be done in one go?

I think it would be ideal to just fix the remainder in one pass. There's not too much left, and it's an easy cleanup...

Comment 17

[bbell]

Attachment: defaultFavicon.png

markh asked for simple PNG replacements. This is the standard sized PNG.

Comment 18

[bbell]

Attachment: [e-mail]

markh asked for simple PNG replacements. This is the @2x sized PNG.

Comment 19

[Mark Hammond [:markh] [:mhammond]]

Attachment: 0001-Bug-1074937-replace-defaultFavicon.png-and-defaultFa.patch

The best laid plans of mice and men...

* Re SVG: the svg size we planned to use is ~60kb, which is large - we could possibly optimize that, but probably not enough to make it competitive with the 445 byte (16x16) or 1162 byte (32x32) versions of the image attached by Bryan. Further, some tests failed in obscure ways when using the svg (something didn't like a text/xml response), so there may be compatibility concerns. Therefore I decided we should stick with .png and investigate using svg in a different bug.

* Re sharing files: Of the 5 png files I tested under "mozapps", 4 were different between the platforms (ie, files of the same name were not identical). I didn't dig into why that's the case, I just decided to not block this favicon change on the quagmire that is certain to be.

So this patch is trivial - it just replaces the 5 existing defaultFavicon.png files with Bryan's.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c9543deefb98

Comment 20

[Marco Bonardo [:mak]]

what if we'd use an .ico file with 16 and 32 resolutions?
I'm asking mostly cause
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsIFaviconService.idl#136
this will keep pointing to the 16x16 png, and that sucks on hi dpi...

Comment 21

[Mark Hammond [:markh] [:mhammond]]

(In reply to Marco Bonardo [::mak] from comment #20)
> what if we'd use an .ico file with 16 and 32 resolutions?

That sounds like an alternative to using a .svg that we can explore in a followup.

Comment 22

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/ab96afd509a0

Comment 23

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/ab96afd509a0

Comment 24

[Ryan Feeley [:rfeeley]]

The globe is a little too light, is it not?

Comment 25

[Stephen Horlander [:shorlander]]

(In reply to Ryan Feeley [:rfeeley] from comment #24)
> The globe is a little too light, is it not?

There is a bug for that: https://bugzilla.mozilla.org/show_bug.cgi?id=1224653