60.92 KB, image/svg+xml
445 bytes, image/png
1.13 KB, image/png
8.70 KB, patch
|Details | Diff | Splinter Review|
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).
Summary: Consider changing the default favicon in the visit URL entry for something better → Consider changing the default favicon in the visit URL entry to something better
I agree, the default favicon doesn't look nice in this context.
Needinfo'ing UX people to have more info.
Yes! Intuitively, I'd go with the globe that we show next to URLs on non-https sites.
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).
Can this be added to the unified autocomplete work ?
yes, it might be part of bug 1181078
(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.
Priority: -- → P3
Summary: Consider changing the default favicon in the visit URL entry to something better → Change the default empty favicon for the awesomebar entries not having a favicon
Assignee: nobody → shorlander
Whiteboard: [unifiedcomplete][fxsearch] → [UX][unifiedcomplete][fxsearch]
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.
do we have a dev or team who's interested in fixing this?
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.
: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
Attachment #8661013 - Flags: ui-review?(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.
4 years ago
Attachment #8661013 - Flags: ui-review?(shorlander) → ui-review+
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.
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.
(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...
Iteration: --- → 44.2 - Oct 19
Whiteboard: [UX][unifiedcomplete][fxsearch] → [UX][unifiedcomplete][fxsearch][fxsync]
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
Attachment #8671712 - Flags: review?(dolske)
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...
(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.
Attachment #8671712 - Flags: review?(dolske) → review+
Summary: Change the default empty favicon for the awesomebar entries not having a favicon → Change the default favicon from an empty dashed-box to a globe.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 44
4 years ago
No longer blocks: 1202712
The globe is a little too light, is it not?
(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
You need to log in before you can comment on or make changes to this bug.