User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060817 BonEcho/2.0b1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060817 BonEcho/2.0b1 In bug 343674, Asa opines that having the tab close button on the same side of the tab as the favicon is 1. aesthetically displeasing and 2. potentially confusing (in cases where the fallback placeholder favicon is displayed). He then suggests that the solution is to move the close button to the right side of the tab, which is the policy that got implemented by the FF2 visual update. I can't tell how much discussion this issue got, since the theme design process is opaque, but given that the implemented fix is radical and destructive, I think it ought to be discussed more publicly. I'll refrain from any HIG invoking ('cause I'm apparently the one Mac user who hasn't read it?), but established precedent says that putting close buttons on the right-hand side of a document tab on Mac OS is wrong. (See http://inessential.com/?comments=1&postid=3329 for Brent Simmons' quick roundup of Mac apps that use tabs to represent multiple documents per window.) Asa had a point about [tab-close, favicon, page title] being kludgy and yuck, but sabotaging the two-decades-old muscle memory of Mac users (close buttons belong on the LEFT) is a far too brutal solution. It would be much better to move the favicon (that is to say, the click-inert UI element that encodes parenthetical [and frequently absent] information, rather than the crucial document-destruction control that users have developed well-honed and *consistent* cross-application instincts to deal with) to the right-hand side of the tab, leaving the close button where every Mac user expects to find it. An additional aid to clarity would be changing the fallback favicon to something non-round on Pinstripe. (The question of whether tab-close controls ought to *look* different in Firefox than they do in every other tabbed application is being handled in bug 347691. This bug is just about placement.) Reproducible: Always Steps to Reproduce: Try to close a tab the same way you would in Safari, Camino, VoodooPad, Transmit, the NetNewsWire browser control, Adium, or Smultron. Actual Results: Failure followed by double-take, because the tab close button is positioned idiosyncratically. Expected Results: Tab closes.

This bug is almost certainly WONTFIX, as there's been extensive discussion about it, but it's worth making the summaries of that discussion public. There really isn't much precedent to guide how to deal with "close button + favicon" here. Adium has a rather elegant hover solution, but it's not discoverable or intuitive. Safari simply avoids showing favicons, which isn't very useful. Anecdotal reports from several developers have been that targeting was definitely improved by separating the favicon and close button, so at least from that perspective, the original problem seems to be a real one. I'm suspicious that changing the default favicon shape would be enough here; plus that would break some consistency itself. However, if someone wants to whip up a patch, it might be worth testing. mconnor reported that he tested "close on left, favicon on right" and it looked extremely bizarre to him. IMO it would probably be worth a public patch to do that to get wider feedback from beltzer et. al, to be very certain that's an inferior solution. CCing beltzner and mconnor and confirming, since others will certainly complain about this issue, and we should be very confident in our answer.

Thank you for making that public. I'm eager to see what people think of it in b2. I think "looking weird" is generally superior to "acting weird," and I'd be interested to try the offending patch for myself. (I'm on classic Pinstripe for the nonce, since I was getting too frustrated with the right-handed close buttons.)

I spent part of the day surfing with the default theme, and that closing button on the right really annoyed me. Personally, I fail to see how having close button on the left, then the favicon, is confusing, or cluttered. The default icon is quite different in look from the close button. Just need to make sure there is enough space between the two. (although In BonEcho, the favicon does nothing beyond a visual marker; in Camino, e.g, the favicon is also a proxy to enable to drag the url from a tab to somewhere else, hence two different actions in a limited space). And, as has been mentioned in comment 0, the close button on the left is sort of an established convention on OS X. Only Opera goes the other way.

Precedent for tabs aside, the close button for the window is on the left ergo, I expect the close button for the tab to be on the left. Putting it on the right makes it feel like some cheap windows hack made the theme. One of the summary statements given in comment 1 states that "Safari simply avoids showing favicons, which isn't very useful." Why isn't that very useful? What are they even for? Do they convey something that the tab titles usually don't? I'm not looking for an answer as this bug is for close button placement, the questions are merely asked for consideration. Favicons strike me as something merely pretty but rather useless, therefore they shouldn't dictate close button placement, rather user expectation should be the prime consideration. Mac users expect the close button on the left.

(In reply to comment #4) > Why isn't [omitting favicons on tabs] very useful? What are they even for? Do they convey something > that the tab titles usually don't? Favicons on the tabs, being colorful and differently-shaped, are a useful information channel--you can tell your Bugzilla tabs from your Livejournal tabs (or what-have-you) faster than you can read. This is cool and worth saving. But he's got an important point buried in there: The *placeholder* favicons--those globe-shaped ones that prompted Asa's original request for rearrangement--are quite useless. They encode no information, and are ultimately just so much clutter--*harmful* clutter, if we're to believe the early reports that separating the favicons and close buttons helped alleviate targeting problems. The globe placeholder should stay around in the title bar, where it marks the place of a useful control, but on tabs? Why NOT kill it. Of the favicons I see on a daily basis, it's the only one that even CAN be mistaken for a close button, so it might be causing half of Asa's original problem anyhow. Or maybe that belongs in a different bug.

(In reply to comment #5) >you can tell your Bugzilla tabs from your Livejournal tabs > (or what-have-you) faster than you can read. This is cool and worth saving. Yes, but several mozillazine tabs open and you're back to reading to distinguish them. The point though was that whatever their utility it isn't so great that they should cause the close button to be moved to a location unexpected by most mac users, which seems to be on the left, in agreement with most tabbed mac programs and the window itself. I'm arguing that more people will notice the tab close button than say a lack of, or relocation of, the favicon. As a suggestion to reduce the targeting problem while maintaining the close button on the left and also the favicon on the left, why not place the favicon adjacent to the tab name rather than the close button? This would open up some additional space between the button and the favicon even on a tab where the name is being truncated as previously there was more space between the favicon and the tab name than the favicon and the close button. I'm not trying to hijack this with discussion of favicon placement, but since that seemed the issue people had, resulting in the tab close button being relocated in the first place, discussing it seems necessary.

RC1 is coming up, and I can't tell whether the devs recognize this as a valid problem. Is this WONTFIX, or is it still being debated?

i'm confused, what do you mean there isn't precedent? finder windows have had icons in their titlebar since at least system 5. they also had close buttons in their titlebar. and surprisingly enough, they also had titles in their titlebar. of course, the way they did this was to tie the icon to the title, center the title, and include some yummy padding around that group so that it was visually distinct. and yes, i know that finder didn't use tabs, i don't care, that's not the point. a close widget + a graphical widget + title was done by apple long before the internet.

*** Bug 350979 has been marked as a duplicate of this bug. ***

*** Bug 354332 has been marked as a duplicate of this bug. ***

I'm submitting this screenshot to illustrate that keeping favicon and close buttons together isn't as horrible as some of you guys are making it out to be and it at least sticks to the expected behavior in OS X of closing something from the left side. Also can I add that the only time a favicon and close button in the current Firefox 2 builds doesn't show up together is on the left and right tabs? Otherwise, they're next to each other right now anyways (just not on the same tab). To me this is a must-fix. Otherwise the current Firefox 2 theme, as someone else pointed out, looks like someone trying to impose Windows UI standards onto a Mac user.

Mark my words - putting the tab close button is un-Mac-like and Firefox developers will be grilled on this decision by the Mac press and Mac users/websites alike. The decision will be reversed if we release Firefox 2.0 with tabs close buttons like this. Mac users will see it as forcing a Windows-style close button on the Mac. The solution is simple - please please move the close box back to the left, Mac side of things. The attachment above shows a mockup of reversing the favicon and the close box - and no it does not look weird. After all, Mac icons for the desktop are on the right. The alternative, keeping both close + favicon on the left (as in Camino) is also acceptable - just please please please move the close box back to the left!

(In reply to comment #12) > The attachment above shows a mockup of reversing the favicon and the close box > - and no it does not look weird. Yes it does, because it doesn't match the favicon being on the left in the address bar.

Yeah, making the favicon on the right because desktop icons are on the right is a little weak. Icons are always to the left or above the label they represent, never to the right. I personally have "Label position" for my desktop icons set to right instead of bottom, so the icon next to the text is to the left of it (there's no setting for making the icon to the right of text). Applications that show a document's icon in the titlebar have it left of the title. When you pull-down your Bookmarks menu in Firefox, the 'List all tabs' button, look at the searchbar and look at the addressbar, they all have the icon left of the text. In fact I think I'd be more annoyed about the icon being on the right than I am about the close button being on the right, but both should be on the left if Firefox wants to function like a native OS X program on OS X. It's always [close] [icon] [title] in that order, whether or not one of those is hidden or there are other things in between, Firefox should not disobey that order. If every application developer on OS X followed their own aesthetic preferences, the desktop would look like a mess and nothing would be consistent.

re: comment #14 - agreed. i think [close] [icon] [title] as in FF2.0 Beta 1 worked well and perhaps we should revert to that. ([close] [title] [icon] as suggested in screenshot was just as an alternative) Another way - what about centering the title (as in Mac OS X title bars). For most cases (where website names are too long), it will be on the left anyway - but for something short - e.g. "Mozilla" or "Google", it would appear in the centre - i.e. [close] [flexible_space] [icon] [title] [flexible_space])

As timeless pointed out, this has been mac typical for quite some time. Why is this not an acceptable template for how to treat the tabs?

Alright, this is the first time I've submitted a patch, so please let me know what i've done wrong other than hoping wildly that this might make some sort of difference. . . Patch is against the FF2 branch. I have no idea how the review thing works or any of it. Any help or suggestions would be appreciated.

Now that tabbrowser.xml has been moved, a different patch is needed on the trunk. I'm guessing this will only help those few that hate the default tab arrangement as much as I do.

Now that the new default theme has landed, with the goal of better OS integration, should this bug get another look? The tab close button is still on the right side of the tab.

It's worth pointing out that every other Mac browser with tab support (Safari, Camino, Shiira, OmniWeb, iCab) displays the tab close button on the correct (left) side.

for years i have had my close button on the left, and favicon on the right, just by adding the following to my userChrome.css: .tab-middle { -moz-box-direction: reverse !important; } it seems perfectly natural and normal this way. imagine my horror on finding that it no longer works in firefox 3! does anyone know how i can get this functionality back? putting a close button on the right is just a horrible, ugly thing to do to a mac user. i've only ever seen it in java or x11 apps that don't look the least bit mac-like. firefox 3 looks great, please don't spoil the great theme work by doing something as blunderingly user-unfriendly as putting the close button on the right! it's like a big zit on the face of an otherwise beautiful new mac firefox look...

my bad - the above code for userChrome.css depends on having the "tab mix plus" extension installed, and the current release wasn't compatible with firefox 3. installing the latest dev version of tab mix plus brings it back! so this is a sort-of-work-around for this bug, tab mix plus gives you an option for "Close tab button" and "Place on left side"; which gives you a close button on the left, with the favicon also on the left just next to it. if you prefer the favicon on the right like i do, then *uncheck* "Place on left side", and add the code from comment 22 to your userChrome.css another work-around is of course to use one of the many OS X themes that properly put the close button on the left in the first place, such as "GrApple". it occurs to me that i should actually be opening a bug on the new firefox 3 mac os x theme, since other themes don't have this problem, and, this bug is on firefox 2 branch tabbed browser component... finally, if you do install eg. the GrApple theme, tab mix plus will over-ride the default button-on-the-left behaviour. so you'll need to either check "Place on left side" (button and favicon both on left), or leave it unchecked and add the code to userChrome.css sorry if that was too much information, hope it helps someone.

I always get confused with the close button being on the wrong side of the tabs. The general paradigm on the Mac is that documents are closed with a button at the top left (the red one!). Why should this be different for the tabs? The tabs seem to be designed by Windows users, who expect the button to be on the right. The current solution appears to be borne by the necessity to display a favicon. Don't forget that viewing is always easier than actually interacting with an element. You only need to view the favicon (in most cases), but you need to interact with the close button: up to once per tab! Why not have the favicon to the left of the (centered) label, and the close button to the left of the tab? That would mirror the layout of windows, where the proxy icon of the document is always immediately adjacent to the window title.

See bug 443860 for a proposal on how the close button should be on the left - but only visible on the active tab, replaced by the favicon on inactive tabs.

My first XUL patch! I realize that it's probably silly to submit a mozilla-central patch on a four-year-old bug for the 2.0 branch, but I'm not sure what the appropriate protocol is. Did we mean to mark it as WNF those years ago? I'm putting it out here under the "it is better to go and make stuff happen" principle. :-) In any case, tweaking the XUL was fun and easy! The one quirk I found is that the mouseout event doesn't trigger when you sweep your mouse over the area *extremely* quickly - I tried using the |this.clientTop| hack that some of the surrounding code seems to use to flush style updates, but it didn't seem to help. Hopefully somebody CC'd on the bug can tell me what's what.

Comment on attachment 448264 [details] [diff] [review] Favicon becomes close icon on hover. Thanks Chris! Faaborg will have to comment on the UI side of the patch, but in my opinion it would be better to have the favicon transform into the close button while the mouse is *anywhere on that tab* instead of directly over the favicon. That would improve discoverability. It would also make the code a little simpler because we wouldn't need any JavaScript. To the code side of the patch: I don't think we should impose this behavior on third-party themes, so the CSS should probably be moved out of content to pinstripe. Not sure what to do about the XUL ifdefs, though... Also, the way you check for the anonid in your mouseover/out handlers will make setting the "overicon" attribute on non-Mac platforms pretty arbitrary, right? (In reply to comment #27) > The one quirk I found is that > the mouseout event doesn't trigger when you sweep your mouse over the area > *extremely* quickly I thought mouseover events were pretty much guaranteed to be paired with mouseout events, so I would have to debug this to find out what happens.

(In reply to comment #28) Thanks for the prompt reply Markus! > it > would be better to have the favicon transform into the close button while the > mouse is *anywhere on that tab* instead of directly over the favicon. I love how UI stuff is totally non-obvious until you think of it. >.< Sounds like a good idea! > we wouldn't need any JavaScript. You mean beyond the |mouseover=this.setAttribute("hovering", "true")|, right? It didn't look like you could use :hover on XUL elements from some examples I saw, but getting rid of the anonid would clean things up nicely. > To the code side of the patch: I don't think we should impose this behavior on > third-party themes, so the CSS should probably be moved out of content to > pinstripe. To clarify: is that because the third-party themes currently might assume the close button in on the RHS? > Not sure what to do about the XUL ifdefs, though... Is it easy to add the same preprocessor to the pinstripe build flow? > Also, the way you check for the anonid in your mouseover/out handlers will make > setting the "overicon" attribute on non-Mac platforms pretty arbitrary, right? Yeah, I wasn't sure whether obfuscating the code with preprocessor junk was worth saving the overhead, especially if extensions could then use that information. Like I said, I'm new around here -- feel free to tell me how it is. :-)

(In reply to comment #29) > > it > > would be better to have the favicon transform into the close button while the > > mouse is *anywhere on that tab* instead of directly over the favicon. > > I love how UI stuff is totally non-obvious until you think of it. >.< Sounds > like a good idea! There's some long discussion on http://code.google.com/p/chromium/issues/detail?id=12035 where different solutions are presented - note especially comment 103 which mentions counter arguments for both our proposed solutions. > > we wouldn't need any JavaScript. > > You mean beyond the |mouseover=this.setAttribute("hovering", "true")|, right? > It didn't look like you could use :hover on XUL elements from some examples I > saw You can :) In pinstripe we're using it for the buttons in the bookmarks bar, for example. > > To the code side of the patch: I don't think we should impose this behavior on > > third-party themes, so the CSS should probably be moved out of content to > > pinstripe. > > To clarify: is that because the third-party themes currently might assume the > close button in on the RHS? Yes, mainly that. But let's talk about the implementation after we have clarity on the UI.

Comment on attachment 448264 [details] [diff] [review] Favicon becomes close icon on hover. Off of the top of my head issues in favor of the change include: -Improved visual appearance (constant effect) -Consistency with the platform's window controls (constant effect) And reasons we shouldn't take the change include: -Poor discoverabilty (one time effect) -Visual noise when moving through the tab strip (constant effect) -Accidental tab closures when the user tries to target the tab by hitting the favicon (semi-regular mistake?) -Inconsistent with Firefox running on other platforms (constant effect, but users in this situation are pretty uncommon). I'm pretty much on the fence on this one, I'm giving it a ui-r+ so that we can try it out with the new OS X theme work, but if someone else on the team strongly disagrees that could easily switch the review. This is one of the least confident ui-r+'s I've set.

Is that ui-r+ on "show the closebutton while the mouse is over the favicon" or on "show it while the mouse is over the tab"?

I'm a bit confused about this discussion, will this have any impact on current versions of Firefox, or is it somehow still about FF 2? In any case... I'd like to suggest that it's more important to have it work smoothly, than to look nice. Of course you'd like to have both, but if you have to choose, choose good functionality. The guy in the google chrome comment 103 says they won't go with any solution that is "more awkward than what we have", and that putting the favicon on the right, or putting both on the left, are ruled out because it "looks like ass". Well, in my opinion, constanty moving my mouse to the left side of the tab to close it, then going "doh!" and moving it to the right, is far more awkward than having something that might look odd. Because it's about functionality, about trying to accomplish an action and stumbling, failing, because the control isn't where you expect it to be. If something looks aesthetically awkward or ugly, that has much less of a negative impact on the user experience, than if it's awkward to *operate*. I have my firefox set up with the favicon on the right, the way that Opera does it. It's simple, obvious, intuitive, and visually balanced. It doesn't "look like ass" to me at all. After a few days you'd be completly used to it. I still think that's the best way to do it. Putting the favicon immediately to the left of the text could be ok. In fact, getting rid of the favicon altogether, the way Safari does, would be fine. The favicon is simply a much less important part of the UI than the close button. I've been trying out Safari with Glims, with the hovering action. Can't say I like it much. I start moving the mouse to the left side to close the tab, but then I see this other icon there that I'm not expecting (as opposed to empty space as in Safari), and I get this feeling of doubt that I'm doing the right action. Maybe I'd learn to get used to that, but I don't want to have to learn, any more than I want to learn to go to the right... Anyway, certainly it would be much better if hovering anywhere on the tab, not just on the favicon, would show the close button. So if it comes down to it, I'd say go that way. Whatever way it's done, having the close button on the left would be a big improvement.

(In reply to comment #31) > -Poor discoverabilty (one time effect) > -Visual noise when moving through the tab strip (constant effect) (I personally dislike the little hover dance that is being suggested) > -Accidental tab closures when the user tries to target the tab by hitting the > favicon (semi-regular mistake?) FWIW, Camino has had favicon-next-to-close-tab-button for ages (since long before Camino 1.0). I can't remember any complain about it. Complains as in: accidentally closing the tab when the user wants the favicon. And bear in mind, in Camino, the favicon is also a file proxy, you can grab it and move the url around (to the Bookmark bar, to the desktop to create a webloc file, to a new window, to ....). In Firefox, the favicon serves no purpose at all beside a bit of decoration / site identification. I don't see any visual noise in Camino's combo, much less actually than the hover dance suggested here.

This bug has become about three separate things: a. putting the tab close on the left instead of the right b. putting the tab close in place of the favicon for the active tab b2. optionally, only making the tab close appear in place of the favicon when the mouse is hovering over the tab. I don't see option b - making the tab close box appear in place of the same-size favicon on the left only when the tab is active - as a hover dance, as swapping the elements doesn't lead to movement of e.g. the tab text. This change depends on being an active tab, not on a mouseover event. The favicon of the active tab also already appears in the url bar, where it can be dragged to the bookmark bar etc. Favicons are therefore redundant in the active tab as repeated - but remain useful in inactive tabs for recognising the tab content at a glance. 'Active tab favicon gets promoted to url bar and replaced with a close tab when the tab is active' is not a hover dance. I'm in favour of option b (favicon always replaced by close box on active tab). option a (close icon next to favicon) is too cluttered. Option b2 (only make close box appear instead of favicon when cursor over active tab) is too complicated for the user. 'The active tab is the one with the close box' is a nice simple rule.

Ah, I missed that for *inactive* tabs, there's replacing the favicon with a close tab while over it - if you want to be able to delete the tab in one action without first making it active. So option b2 describes the active tab only!

@Aaron thanks for marking my bug as duplicate. I see NO reason why the favicon on the right side would look uglier than on the left. That argument just doesn't make any sense. Srsly. It's just blocking progress of this bug. The positions (Favicon - Close button) just need to be switched. That's it. It'll look great, AS great as it looks now, and without noticing them selfs, it'll make Firefox feel more comfortable for people attached to Mac OSX. Myself included. At the moment I always focus the wrong corner first, because I'm currently used to Mac. IMHO this Bug is one of the reasons why many Mac users "just" prefer Safari - I better fits their using habits.

> The positions (Favicon - Close button) just need to be switched. That's it. Not really. Tab close boxes need more fixes than that. This bug is really about: a. putting the tab close on the left instead of the right b. putting the tab close in place of the favicon for the active tab whose favicon is now in the url bar (with some minor variations). See bug 443860 which also satisfies Mac users.

No idea why this bug is still open, I don't think this is up for debate. * Apple ships lots of products of their own with close button on the right side (iChat, Pages, Automator, etc) * Having the favicon on the right side makes it harder for LTR audience to identify tabs, which they do even more than closing tabs * Hiding the close button and showing it on hover has poor discoverability (and yes, I know Safari does this, WTF ;)

@40 - what is 'LTR audience'? On discoverability - hiding the close button to make more space for title text helps with discoverability. I'm all for hiding the close button behind favicons except on the active tab, where the close button is shown. This makes for efficient use of space, and also 'promotes' the favicon of the existing tab to the URL bar, instead of duplicating it. Since you can't e.g drag tab favicons to bookmarks, but must drag the icon next to the url, this would be an improvement. Seeing favicons is useful for identifying which tab you want and discovering it; seeing multiple close boxes is not. bug 443860 goes into this in detail. As a UX point, note that the X of the tab close button is very different from the 'stop loading this page' X in the toolbar icons (which even says page when multiple tabs are open). That one needs a rethink...

"LTR audience" refers to languages that are written and read left-to-right.