686633 - Remove the favicon from the address bar

Status: RESOLVED DUPLICATE of bug 587901

(Firefox :: Address Bar, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

Currently, the user interface of Firefox provides two places to see a websites favicon: the address bar and the tab. 

Implications:
1. Users will not be able to drag the favicon to their desktop or bookmarks sidebar/toolbar to create a shortcut. This can still be accomplished by highlighting the address and dragging.
2. Users will not be able to access site identity information through the address bar if not on SSL connection. Workaround: Context-menu -> View Page Info -> Security

Reasons this makes sense:
1. Removing redundancy and cleaning up the address bar to have less visual noise.
2. Reducing the impact of a site setting their favicon to a padlock to give users a false sense of browsing over SSL.
3. We cannot remove the favicon from tabs because they are necessary for App Tabs as well as providing users with more knowledge about what site they are about to view when switching tabs.

Comment 1

[Masatoshi Kimura [:emk]]

> 1. Users will not be able to drag the favicon to their desktop or bookmarks
> sidebar/toolbar to create a shortcut. This can still be accomplished by
> highlighting the address and dragging.
I couldn't drag the highlighted address to the desktop.
Mozilla guys removed a "drag tab to desktop" feature. At that time they said "You can still drag favicon to the desktop". Now you are going to remove favicon, too. Great. Then how can I create a shortcut on the desktop?

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Masatoshi Kimura [:emk] from comment #1)
> > 1. Users will not be able to drag the favicon to their desktop or bookmarks
> > sidebar/toolbar to create a shortcut. This can still be accomplished by
> > highlighting the address and dragging.
> I couldn't drag the highlighted address to the desktop.
> Mozilla guys removed a "drag tab to desktop" feature. At that time they said
> "You can still drag favicon to the desktop". Now you are going to remove
> favicon, too. Great. Then how can I create a shortcut on the desktop?

It seems that dragging the address to the desktop might solve your problem, but that doesn't appear to work at the moment. If that issue was fixed would that make this change more acceptable?

Comment 3

[Masatoshi Kimura [:emk]]

(In reply to Jared Wein [:jwein] from comment #2)
> It seems that dragging the address to the desktop might solve your problem,
> but that doesn't appear to work at the moment. If that issue was fixed would
> that make this change more acceptable?
I found another problem. When I dragged a favicon to the bookmarks sidebar/toolbar, page title is automatically set as the bookmark name. But when I drag the address to the bookmarks, the URL becomes the bookmarks name. I had to open Page Info, copy the page title, and rename the bookmark manually.
I don't mind if those problems are resolved.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Masatoshi Kimura [:emk] from comment #3)
> I found another problem. When I dragged a favicon to the bookmarks
> sidebar/toolbar, page title is automatically set as the bookmark name. But
> when I drag the address to the bookmarks, the URL becomes the bookmarks
> name. I had to open Page Info, copy the page title, and rename the bookmark
> manually.
> I don't mind if those problems are resolved.

Thanks for pointing out these issues. Yeah, if we do this we will want to make sure that those experiences are better :)

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Screenshot of WIP

This screenshot shows what could the change could look like. There are four windows in the screenshot. From top to bottom, the first window shows an EV SSL connection, the second window shows an SSL connection, the third window shows a mixed-content SSL connection, and the third window shows a non-SSL connection.

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: WIP for bug 686633

This is the work-in-progress of this patch. We probably don't need the page-proxy-stack anymore, but I have left it in for now because I didn't want to break anything else for this WIP yet.

As mentioned in earlier comments, this bug is probably blocked until the other improvements to shortcut-creation are fixed (those bugs will need to be, if not already, logged and marked as blocking this bug).

Comment 7

[Frank Yan (:fryn)]

Comment on attachment 560122 [details] [diff] [review]
WIP for bug 686633

I think this bug really needs to be blocked on having a replacement drag target for the page. If anything, the bookmark star looks like a viable candidate for this.

We should also consider attaching metadata that includes the page title to the list of drag flavors available when dragging the full url of the page to the desktop.

I don't think that the urlbar-throbber is especially useful, and I'd advocate for removing it entirely. If, in the rare case, that the awesomebar results are slow to load, there is also rarely a need for the user to wait for them. The user can simply press enter to perform a search. In this case, a throbber makes Firefox feel slower.

If we decide to remove the favicon, let's remove #page-proxy-stack entirely.

For this particular patch, the identity block needs more padding-start.

What is the purpose of having this WIP patch? Are you planning to land this on the UX branch? If so, I think it'd be more useful to land a more complete patch that at least makes an attempt to solve the drag target problem, e.g. enabling the bookmark star to be dragged, rather than simply to remove things to "see how it feels", since we already know that we prefer the visual effect of not having the duplicate favicon, so landing it wouldn't answer any questions.

Comment 8

[Frank Yan (:fryn)]

I hope I didn't discourage you in the above comment; I didn't mean to. To clarify: it's fantastic that you've started on a patch and uploaded it. Taking the initiative and responsibility to own a bug is great. I asked the above questions, because I think it is important that we be able to show that we know where we're going with this. Simply landing the favicon removal could easily be misinterpreted as "removing stuff for the sake of removing stuff". I gave it feedback-, because I don't want it landed on the UX branch for the aforementioned reasons.

Comment 9

[Dão Gottwald [:dao]]

Duping against bug 587901, which contains relevant history. Reopen that bug as needed.

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Frank Yan [:fryn] from comment #7) 
> I think this bug really needs to be blocked on having a replacement drag
> target for the page. If anything, the bookmark star looks like a viable
> candidate for this.

Agreed. That is a good idea to use the bookmark star. I'm not sure how intuitive it will be for users to use the bookmark star, but then again, the favicon wasn't intuitive either.

> We should also consider attaching metadata that includes the page title to
> the list of drag flavors available when dragging the full url of the page to
> the desktop.

Yeah, we'll need to do that as well.

> I don't think that the urlbar-throbber is especially useful, and I'd
> advocate for removing it entirely. If, in the rare case, that the awesomebar
> results are slow to load, there is also rarely a need for the user to wait
> for them. The user can simply press enter to perform a search. In this case,
> a throbber makes Firefox feel slower.
> 
> If we decide to remove the favicon, let's remove #page-proxy-stack entirely.

OK, that answers my previous question and gives us a little win at the same time. :)

> For this particular patch, the identity block needs more padding-start.

Noted.
 
> What is the purpose of having this WIP patch? Are you planning to land this
> on the UX branch?

I uploaded this patch simply as part of working in the open. As mentioned before, the blocking issues will need to be fixed first before continuing. Maybe when all of those issues are fixed and this patch is complete, we could push it to UX, but not any time sooner.

With all of that being said, this bug has been closed and any future work should be done in bug 587901. I won't take that bug yet, since I'm not sure if I will have the time. Thanks for the feedback! :)

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

>Duping against bug 587901, which contains relevant history. Reopen that bug as needed.

That bug was wontfixed in the specific context of Firefox 4.  The downside to reopening that bug is that it has 49 dissenting users cc'd on it, and the strategy of turning every individual ui change into a riot is a slow and ineffective way for us to implement our new theme.

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

Let's continue work in bug 588270, which was the long term plan anyway.