Alex Faaborg

I realise that a conscious decision may have been made to implement them this way, and that to do them “correctly” in Firefox is probably difficult but select-boxes do not look completely native on OS X, per bug 402625.

427973 please…

For a future post, I guess this one deserves some exposure:

Location bar should encode parentheses on copy

An example of polishing bug which is not directly related to visual rendering of elements, and which I believe would be also relatively easy to fix.

Now that the tab bar is always visible, isn’t it time to remove the favicon from the location bar? Don’t need two of those for sure. -Cato

“Now that the tab bar is always visible, isn’t it time to remove the favicon from the location bar? Don’t need two of those for sure.”

I don’t think its as simple as there just being two favicons. If one is going to be removed, shouldn’t it be the one on tabs? Tabs relate to specific pages, and the site button (in the location bar) generally relates to the entire site. You don’t really ever see a favicon change for each page on a site - they almost always identify an entire site. So it makes more sense to use the favicon in the context of the entire site (i.e. the site button in the location bar), rather than on tabs.

But IMO both should stay. They serve different purposes (the site button has it’s functions and the favicons on tabs serve to distinguish tabs from each other easily).

I think the one in the location bar should be removed, since favicons are very useful when navigating with the tabs. It’s quicker for the eyes to find the correct tab if the favicon is on it. The favicon in the location bar however, do not serve much of a purpose. I heard Faaborg himself wants it gone too. True, I hope.

I agree, favicons are practically essential for navigating tabs. But the favicon for a given site is also a most excellent icon for the site button, so it’s not as simple as just saying there are two favicons and we only need one. There would need to be a suitable replacement icon for the site button that would be just as effective as or more effective than using the favicon.

About the favicons, I was thinking that if the tabbar is hidden, the favicons should be kept equal. If not, then the address bar should not show a favicon, but something related to the location and the security of the site itself. For example, normal sites would have a globe icon; local sites a folder; secure sites something more to show they are secure, as a lock, or their real favicon (together with the actual system to show secure sites), to make sure no scams are made.

Also, relativelly to bug 413881

https://bugzilla.mozilla.org/show_bug.cgi?id=413881

I think the tabbar could be more native on Linux by using the “-moz-appearance: tabpanels;” CSS property on the box with class tabs-bottom and a lot of retouch stuff and bug fixing so tabs actually integrate all the time unlike the glitch with tabs redrawing themselves incorrectly.

On Windows, the awsomebar could have some rework with the new CSS 3 border-radius properties that were added to Firefox so it wont uses negative margins. That way it is also easier to make the awsomebar itself native and make the site icon part the way it looks now, adding some negative margin to hide the left part of the urlbar (if this seems messy I can provide some links to some mockups explaining better).

About the favicons…

I think the most common reason to keep 2 favicons is that there is nothing better to put at the site button. But without the favicon, the site button could be a lot “lighter”.

Think about it.

Looks like Polishing Firefox got interrupted again

I’d like to suggest another polishing bug for OS X: Unified titlebar/toolbar gradient broken after hiding toolbar. Screenshots included.