457651 - New Tab button should be right of last tab

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P1)

Description

[Damian Shaw [Quan]]

The new 'new tab' button is placed very out of range of discoverability for users new to tabbing and far away for the sake of convenience.

In the study done on the close tab position ( http://people.mozilla.com/~faaborg/files/20070509-CHI2007/p1783.pdf ) it was hypothesised from data results that the far right position of the close tab button make discovability very low for new users. Surely the same idea can be applied to the new tab button?

Also bug 457187 related

Comment 1

[Jo Hermans]

This would make it similar to Chrome. However it also makes it a moving target, which goes against Fitt's Law. The current solution isn't good either, since it's easy to miss.

Maybe it's better to place it on the left hand side, which would make it similar to Opera's solution.

Comment 2

[Damian Shaw [Quan]]

Well I suppose another option would be to make it right of current tab, so it creates a tab in between the current and the next tab.

Comment 3

[Ria Klaassen (not reading all bugmail)]

I agree with Jo that the button should stay on one spot. In my view the current place on the right side near the tabs menu button is the best, because the mouse cursor is also mostly on the right side of the page which makes the button faster accessible.

Comment 4

[Damian Shaw [Quan]]

(In reply to comment #3)
> I agree with Jo that the button should stay on one spot. In my view the current
> place on the right side near the tabs menu button is the best, because the
> mouse cursor is also mostly on the right side of the page which makes the
> button faster accessible.

What evidence do you have to support this? My personal experience does not reflect this at all and I find the set-up very annoying. I put the old 'new tab' button near the forward/backward button because my mouse is generally on the left side of the window.

Also Microsoft, Google and Opera have all come to the conclusion that the gain of intuitiveness and discoverability outweigh the downside of a moving button, please don't dismiss such a suggestion out of hand.

Comment 5

[Nochum Sossonko [:Natch]]

IMO putting it next to the current tab isn't really making it a "moving target" because relative to the current tab it's in the same place, something like cruise control on the steering wheel (I know it's a bad example can't think of anything else atm;). Plus it just makes sense that the new tab button should be where the new tab is appearing...
>reflect this at all and I find the set-up very annoying. I put the old 'new
>tab' button near the forward/backward button because my mouse is generally on
Can't agree more!

Comment 6

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #4)
> What evidence do you have to support this?

The same evidence as you have: personal experience. Normally my mouse rests on the bottom right part of the window as the operating base, if I click a link or a chrome button, it only leaves this spot for a split second, then it moves back. This spot is not random: on the right bottom spot I expect least page objects so an unintended click has mostly no consequences. I'm a full time mouse user, only rarely I use keys or shortcuts to navigate.

Comment 7

[Damian Shaw [Quan]]

(In reply to comment #6)
> (In reply to comment #4)
> > What evidence do you have to support this?
> 
> The same evidence as you have: personal experience. 

I wasn't presenting mine as evidence but rather just as a counter example, I was trying to show that personal experience is anecdotal evidence at best.

However the study done for Mozilla on the close tab button:

http://people.mozilla.com/~faaborg/files/20070509-CHI2007/p1783.pdf

Seems to infer that the far right of the tab bar is undiscoverable for new users (2nd page last paragraph). The intent of the new 'new tab' button appears to be increased discoverability. Assuming both these things hold true, then this seems far more important to consider than anecdotal evidence.

Comment 8

[Tyler Downer [He/Him]]

Damian, I agree with the others that the New Tab button should remain where it is(stationary), but  Bug 457187 could be something to interest you.

Comment 9

[Damian Shaw [Quan]]

(In reply to comment #8)
> Damian, I agree with the others that the New Tab button should remain where it
> is(stationary), but  Bug 457187 could be something to interest you.

Like I say, I don't think this should be a matter of personal taste, mine included, I think there should be careful consideration of user interaction as a whole. Also I wrote that bug :-P.

Nominating for wanted, this should either be pushed for 3.1 or marked won'tfix, I don't see as there's any point going in between and leaving it in the works forever.

Comment 10

[Tyler Downer [He/Him]]

Damian, I know you wrote that bug :), I was just posting it for the others on this one (sorry if I worded it poorly). As it is, I really don't think this should be the behavior with FF new tab at all, but if it is, I would like to see it as an option, and most likely not enabled by default (though that would likely defeat the purpose).

Comment 11

[Damian Shaw [Quan]]

Given the recent status meeting:

https://wiki.mozilla.org/WeeklyUpdates/2008-10-06

Which talks about getting only blocking bugs done, I'm nominating for blocking. This should either make it for 3.1 or be marked WON'TFIX (i.e there should be a decision on what is the best UI method and not just leave it for some other release).

Comment 12

[Damian Shaw [Quan]]

The patch is bug 347930 so far makes it 'almost' possible to manually make this change. Assuming bugs with that are fixed, it should be easy enough to set it as default behavior if this is what devs decide.

Comment 13

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

Beltzner and I are both in favor of placing the new tab button to the right of the existing tabs.  The main reasons for this placement are:

1) Natural mapping with where the tab will be created
2) External consistency with other browsers, making it easier for users to transition to Firefox

One caveat is that when the tab strip goes into tab overflow mode, the new tab button should appear to the right of the right arrow (like it currently does), so that it is always visible.

Ideally the placement should still be customizable, but I'm not sure what it would take to get that implemented.

Comment 14

[Damian Shaw [Quan]]

(In reply to comment #13)
> Ideally the placement should still be customizable, but I'm not sure what it
> would take to get that implemented.

If the tab bar becomes a tab toolbar as in bug 347960, then it's simply a matter of setting the default set-up on the tab bar to be:

[tabs][new tab button][flexible white space][all tabs button]

You can sort of do this at the moment in the patch from bug 347930, but it requires about 6 flexible white spaces, hopefully this will be fixed. This also makes things very customizable.

Comment 15

[Dão Gottwald [:dao]]

Here's what I'm thinking. It's basically a summary of what I wrote in an e-mail conversation with Alex:

Natural mapping: I'm not convinced that the mapping between the "new tab" button and the actual tab element that will be created is so natural. Right after opening the tab, you aren't interacting with the tab element itself but rather with the location bar, bookmarks toolbar etc.. /Where/ the tab will be created doesn't actually matter at that point, and a moving "new tab" button isn't supportive of that work flow.

Mouse movement: Depends on how many tabs you have. With a couple of tabs open, you'll have to move your mouse all the way to the right again, which seems to be the current setup's major point of criticism. In this regard, it would make more sense to put the button on the far left.

Consistency with IE7 or other browsers in general: Far less important than the other points in my view.

Comment 16

[Damian Shaw [Quan]]

I don't disagree with those comments Dão, putting the tab on the far left might be a good idea. But there seemed to be no serious developer discussion about its placement when it got put on to the tab bar that involved important factors like discoverability and required mouse movement. Which is a real shame when previous evidence and analysis of button position seems to show that this is a really bad place to put something to be discovered and awkward to move the mouse there.

Comment 17

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

>there seemed to be no serious developer discussion about
>its placement when it got put on to the tab bar that involved important factors

That doesn't bother me too much, since we don't have to completely think through every change before we test something out in nightly builds.

>Which is a real shame

What's important is that we look at all of the principles and make sure we are making the most scientific decision before we freeze.

>I'm not convinced that the mapping between the "new tab"
>button and the actual tab element that will be created is so natural.

It's not just a natural mapping, it is a direct mapping, the control is placed literally in the same location where the new object will exist.  It's like putting the light switch right on the light bulb, it's hard to get more direct or natural than that.  The natural (or in this case direct) mapping also comes into play with discoverability, visually grouping the + button with a series of tabs to the left creates an interface that is more self describing than putting a + somewhere else in the UI.  

>Mouse movement: Depends on how many tabs you have.

Actually calculating which position would minimize mouse movement would take a whole lot of data and would also depend on what their next target is likely to be, which is effected by the design of the new tab page, so so it really is hard to conclude if far left is much better or worse than next to the most recent tab.  Far right is pretty clearly worse than both of those though.

>Consistency with IE7 or other browsers in general: Far less important than the
>other points in my view.

Really? connor usually argues that initial adoptability is the single most important factor to our success, and initial adoptability drives nearly every design decision that we make (or in most cases, don't make).

Comment 18

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

>uiwanted

The UI is described in comment #13

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

Connor and I finally got a chance to sync up on a bunch of stuff. Sadly, he's of the opinion that bug 347930 is too risky to take at this point, and I'm forced to agree. It's where we want to go long term.

In the meantime, as Quan points out, since we just added this without a ton of thought, and since Alex and I worked to create a better design, we should pull the trigger on that. Where possible (ie: non-overflow cases) we should put the new tab button precisely where the new tab will appear, and where the user's eyes will be when thinking "I want to have a new tab appear there", which is to the immediate right of the last tab on the strip (or to the left in RTL, of course). When that isn't possible (ie: overflow case) then it should appear in a place that indicates where the tab will appear, which is to the far right (or left in RTL) side of the strip, indicated by being to the right of the arrow.

So:

.---------,.---,                       :
| Tab 1   || + |                       |

.---------,.---------,.---,            :
| Tab 1   || Tab 2   || + |            |

.---------,     .---------,:   :   :   :
| Tab 1   | ... | Tab N   || > | + | U |

Comment 20

[eyal gruss]

IMHO, new tabs are usually opened with double clicking on empty tab bar space. the new tab icon is necessary when there two many tabs open such that there is empty space to click on. in this case the new tab icon is already on the right of last tab. what is needed perhaps is better discoverability of the double clicking option.

Comment 21

[Frank Freibuth]

This should be blocking 3.1 and not 3.1+.
Introducing a new default "new tab" button in 3.1 and (re)moving it again in the next build is just bad consistency.
And there simply is too much wrong with the current new "new tab" button in Minefield. It's not just its rather odd position, the tab button needs to be bigger as well: It has been a drag-and-drop zone since 1.5 and its current minuscule size and crowded position makes it a very tricky target.

Comment 22

[Damian Shaw [Quan]]

Frank Freibuth: blocking-firefox3.1 +, means that it's blocking 3.1, if it was for a future version it would be described as next, not firefox3.1.

You may also be interested in bug 457150 where I argued that point that it was too close to other buttons as well, but devs don't seem to agree.

Comment 23

[Frank Freibuth]

Thank you, I wasn't aware of that. Well, that's good then. :-)
I voted for #457150 as well, although that would be resolved by moving the button right of the last tab anyways.
People seem to forget or simply are unaware of the fact that the "new tab" button is a drag and drop zone and has been for years!
This is an incredibly useful feature that allows dragging basically anything on the button (regular links, non-clickable links, bookmarks, tabs from another window and even search terms) to open it in a new tab - the current version of the "new tab" button seems to offer this feature only by accident and makes it incredibly hard to use due to its tiny size and position squeezed between two much less important (and seemingly even bigger) buttons.
Well my point is: The current version of the "new tab" button in Minefield has some serious usability problems and IMHO is the worst execution of the "new tab" problem of any current browser, even worse than the old button that at least had a reasonably sized drag-and-drop area and could be positioned rather freely.
As long as we can't come up with a much better solution, Firefox 3.1 should offer the same style of "new tab" button that Opera, Microsoft and Google went with.
The proposed new tab screen http://www.azarask.in/blog/post/new-tabs/ makes this button way too important to make it one of the least usable and least prominent buttons there currently are. It should be one of the most usable.

Comment 24

[Tyler Downer [He/Him]]

If blocking Firefox 3.1 is approved, then it is wanted.

Comment 25

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

beltzner, mconnor: we should get this assigned

Comment 26

[Ed Lee :Mardak]

Why can't we just make the empty tab space clickable and have it create a new tab? Currently people double-click it to make a new tab. We can show the + icon to the right of the last tab unless we're overflowing tabs.

Comment 27

[Ed Lee :Mardak]

Just to be clear, something like..

___________________________________
|______|_______| + (Open a new tab)
-----------------------------------

Where the text shows up on hover anywhere in that empty space. There's no clear "end" to the button, but the + should look clickable. Hovering over the button or the empty space will give the whole empty space an "active" look as well as the +.

Comment 28

[Jo Hermans]

You mean that you consider the entire empty space 1 large button, although it's not really displayed as one (just the icon and maybe some test, but not raised like a button). That's a nice idea for the UI.

Comment 29

[Damian Shaw [Quan]]

(In reply to comment #26)
> Why can't we just make the empty tab space clickable and have it create a new
> tab? Currently people double-click it to make a new tab. We can show the + icon
> to the right of the last tab unless we're overflowing tabs.

Because it's not visually intuitive? I've been using Firefox since before 1.0 and I only heard about double clicking the empty space since reporting these new tab bugs for 3.1.(In reply to comment #27)
> Just to be clear, something like..
> 
> ___________________________________
> |______|_______| + (Open a new tab)
> -----------------------------------
> 
> Where the text shows up on hover anywhere in that empty space. There's no clear
> "end" to the button, but the + should look clickable. Hovering over the button
> or the empty space will give the whole empty space an "active" look as well as
> the +.

This seems like a really good idea. Double clicking on the space hasn't been very visually intuitive, I've been using Firefox since 1.0 and only heard about it since reporting new tab bugs for 3.1. This would make it very visually intuitive and give users a big obvious space to click open a new tab.

Comment 30

[Damian Shaw [Quan]]

Argh! Ignore my reply to comment #26 I wrote that before I read comment #27, didn't realise it was still in the text box.

Comment 31

[Ed Lee :Mardak]

Attachment: mockup fat new-tab

A quick tweaking around DOMi moving the new tab button and various changes..

new button:
style border-left: 0
pack: start
label: Open a new tab (same as tooltiptext)

label inside button:
style: remove the display: none; for hover

I do have to say it's pretty hacky because I place the new tab inside the scrollbox (to avoid flex issues) but then it'll confuse things like ctrl-tab and tab switching that might think it's actually a tab.

Comment 32

[Frank Freibuth]

Please also strongly consider increasing the size of the "new tab" button, especially when it is still the plan to squeeze it between the overflow arrow and the tab switcher in case of overflow. It is considerably more important than those buttons and the design not only has to reflect that but also make it easier to click this button.

Comment 33

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

Mardak: downside is the visual noise when you are mousing towards something on the other side of the tab strip.  Also, once the user has learned the purpose of the control, the interface feels overly verbose, which is why we like to put these types of descriptions in transient tooltips.

Comment 34

[Marco Bonardo [:mak]]

can i only suggest that, if we go for actual idea to put new tab button near All Tabs in case of tabbar overflow, it could be a bit larger than actual implementation? it's hard to click, so small.

Comment 35

[Aaron Sloman]

Nobody seems to have considered people like me. I have been using tabs for a long time and once I discovered that I could use 'customize' to get a "new window" button and a "new tab" button together to the right of the "help"  button, I have been using that layout, and find it very useful having them so close together since their function is so similar (FOR THIS USER -- you may be different).

Consequently I find it *extremely* annoying, on trying Minefield, to discover that somebody has decided that my preference is WRONG, and not only put the button in a different place but made it unmovable.

I don't want it on the tab bar (a) because I am used to having it next to the "new window button" and (b) because I often have a lot of tabs open (I use Firefox as my working memory) and all the space in the tab bar is precious.

I don't care where the new tab button is by default, and I think debates about it are pretty futile because you cannot possibly know what is best for millions of users all round the world with different preferences, in different cultures, different individual backgrounds, etc. However it should be possible for experienced users to move it to where they want it, and that choice should survive restarts of the browser. So please make it movable, as it used to be.
Thanks.

Comment 36

[Damian Shaw [Quan]]

(In reply to comment #35)
> I don't care where the new tab button is by default

Please see bug 457187 and try and avoid bug spam:

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 37

[Aaron Sloman]

(In reply to comment #36)
> (In reply to comment #35)
> > I don't care where the new tab button is by default
> 
> Please see bug 457187 and try and avoid bug spam:
> 
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

I somehow failed to notice bug 457187 when searching to see if my problem had been discussed, and when I found that discussion of this one already included the requirement for position to be customizable (see comment #13) I thought it sensible to add weight to that suggestion rather than start a new discussion. Later, I discovered bug 457187 and made the point there too. I apologise for the duplication, though I don't think the importance of giving the user the right to change the location from the default is irrelevant to the discussion of where the default should be.

If the position can easily be changed by the user (e.g. by dragging it to a desired location, as was previously possible) the importance of the initial location diminishes.

Comment 38

[Damian Shaw [Quan]]

(In reply to comment #37)
> If the position can easily be changed by the user (e.g. by dragging it to a
> desired location, as was previously possible) the importance of the initial
> location diminishes.

While you may feel that that's true, studies show that most users never customise computer interfaces and leave almost all settings to default. So the importance only diminishes ever so slightly.

I completely agree of the importance of bug 457187 which is why I filed it. However the development team don't feel it's blocking and thus the patch which fixes it in bug 347930 is considered too risky to bring on at this stage of release. 

I assure you that 99% of the time the Firefox development team are fully aware of usage cases and how particular users feel about certain changes, but there are many other factors to take in to account other than a small section of users. Unless you can present new evidence for a bug and not just personal experience then I'm afraid it don't do much to add your opinion on mature, well known, bugs like these.

For your own personal experience, extensions already exist to make the tab button customisable to a point or in fact reintroduce the old button.

Comment 39

[Nochum Sossonko [:Natch]]

Attachment: Wip patch

Wip patch, probably not the way to go as it tanks the use of gBrowser.mTabContainer.childNodes, just couldn't find another way to do this. I also didn't implement the overflow status of the new tab button, and I didn't test it on rtl builds, which I'm pretty sure it'll break somehow. ;)

Can this be done with an overlay? And if so, will it affect the childNodes of mTabContainer?

Comment 40

[Nochum Sossonko [:Natch]]

Attachment: Screenshot of proposed button

Here's a screenshot of what the button looks like in the attached patch.

Comment 41

[Nochum Sossonko [:Natch]]

Attachment: More

This is a more complete impl. All todos mentioned previously are fixed. Works in rtl as well and switches to beyond the arrowscrollbox when overflowed. I still didn't redesign the css for mac and linux (only winstripe) as I'm waiting on some feedback if this is the right approach and mainly if the button looks OK ui-wise. One thing I did change in this one is I restored the hover effect, dunno for better or worse, I'll attach a new screen shot momentarily.

Comment 42

[Nochum Sossonko [:Natch]]

Attachment: Screenshot of proposed button

Multiple states shown.

Comment 43

[Nochum Sossonko [:Natch]]

Attachment: patch ver. 1

This should be ready for review.

Comment 44

[Nochum Sossonko [:Natch]]

Attachment: A little more sane css

Just rearranged the css a little better. Additionally some tests will have to be reworked a little, as from initial searches some of them use gBrowser.mTabContainer.childNodes...

Comment 45

[Alice0775 White]

(In reply to comment #44)
> Created an attachment (id=354023) [details]
> A little more sane css
> 
> Just rearranged the css a little better. Additionally some tests will have to
> be reworked a little, as from initial searches some of them use
> gBrowser.mTabContainer.childNodes...

This patch will destroy much Tab-related extensions (such as Tree Style Tab, Tab Mix Plus, Tab Kit, Tab catalog and so on...).
Because the reason is because it uses gBrowser.mTabContainer.childNode by many extensions.
Therefore, I think that it is undesirable to change handling of gBrowser.mTabContainer.childNode.

Comment 46

[Nochum Sossonko [:Natch]]

(In reply to comment #45)

AFAIK it isn't really possible to make the tab button appear next to the current tab without tanking gBrowser.mTabContainer.childNodes, unless the whole tab-browser widget is redone which would be basically bug 347930, this approach is safer code-wise but would be a huge late-compat change. Being that bug 347930 was pushed to a later release, this seems like the only way to do it otherwise. If there's a better way of doing this feel free to comment/upload patches ;-) . As a side note: I don't think it makes sense for extensions in general to rely on gBrowser.mTabContainer.childNodes (or for the same reason gBrowser.tabContainer.childNodes) when a specific attribute of mTabs is provided, even if this patch doesn't get accepted extensions should use mTabs.

Comment 47

[Alice0775 White]

(In reply to comment #46)
> (In reply to comment #45)
> 
> AFAIK it isn't really possible to make the tab button appear next to the
> current tab without tanking gBrowser.mTabContainer.childNodes, unless the whole
> tab-browser widget is redone which would be basically bug 347930, this approach
> is safer code-wise but would be a huge late-compat change. Being that bug
> 347930 was pushed to a later release, this seems like the only way to do it
> otherwise. If there's a better way of doing this feel free to comment/upload
> patches ;-) . As a side note: I don't think it makes sense for extensions in
> general to rely on gBrowser.mTabContainer.childNodes (or for the same reason
> gBrowser.tabContainer.childNodes) when a specific attribute of mTabs is
> provided, even if this patch doesn't get accepted extensions should use mTabs.

OK. but we must pay attention that the extension author has already worked on a change toward 3.1 release.

Comment 48

[Dão Gottwald [:dao]]

(In reply to comment #46)
> (In reply to comment #45)
> 
> AFAIK it isn't really possible to make the tab button appear next to the
> current tab without tanking gBrowser.mTabContainer.childNodes, unless the whole
> tab-browser widget is redone which would be basically bug 347930, this approach
> is safer code-wise but would be a huge late-compat change.

In fact, the patch in bug 347930 would have less impact on most extensions than what you're doing.

> As a side note: I don't think it makes sense for extensions in
> general to rely on gBrowser.mTabContainer.childNodes (or for the same reason
> gBrowser.tabContainer.childNodes) when a specific attribute of mTabs is
> provided, even if this patch doesn't get accepted extensions should use mTabs.

tabContainer.childNodes is the official API, mTabs is private.

Comment 49

[Damian Shaw [Quan]]

Wasn't it made explicit that the only extension incompatibility that should occur from beta 2 to beta 3 was tab stuff? Especially given that tab tearing still isn't properly sorted.

Wasn't bug 347930 thought to be risky because of potential security problems (or at least a proposed security fix would of actually broken it) rather than extension compatibilities?

Comment 50

[Dão Gottwald [:dao]]

(In reply to comment #49)
> Wasn't it made explicit that the only extension incompatibility that should
> occur from beta 2 to beta 3 was tab stuff? Especially given that tab tearing
> still isn't properly sorted.

This doesn't mean that we can break fundamental APIs arbitrarily.

> Wasn't bug 347930 thought to be risky because of potential security problems
> (or at least a proposed security fix would of actually broken it) rather than
> extension compatibilities?

Not to my knowledge.

Comment 51

[Damian Shaw [Quan]]

(In reply to comment #50)
> Not to my knowledge.

Well that's the way I read the conversation between bz and Mossop in #Developers over IRC when he suggested that the patch in bug 347930 should be given review-.

Comment 52

[Dão Gottwald [:dao]]

wanted‑firefox3.1- and review- (which the patch doesn't have) are two different things.

Comment 53

[Damian Shaw [Quan]]

(In reply to comment #52)
> wanted‑firefox3.1- and review- (which the patch doesn't have) are two different
> things.

I didn't want to bugspam so I tried messaging you on IRC, alas I'm not sure you got the message.

Anyway, given and suggested are also 2 different things, bz definitely suggested the patch should get review- but Mossop obviously decided against that in the end.

Comment 54

[Nochum Sossonko [:Natch]]

Comment on attachment 354023 [details] [diff] [review]
A little more sane css

Gonna try to do this a little better, and hopefully without any late-compat changes...

Comment 55

[Nochum Sossonko [:Natch]]

Attachment: Better patch

Ok, here's the promised patch. The behavior of gBrowser.tabContainer.childNodes is restored as the new tab button is brought in via xbl and completely hidden. Hope this will do...

Comment 56

[Dão Gottwald [:dao]]

Comment on attachment 354365 [details] [diff] [review]
Better patch

That's better, thanks!

>-            <children/>
>+            <children includes="tab"/>

Is that change necessary?

>+      <field name="mTabsNewtabButton">

I think most of the time we're using _fooBar instead of mFooBar for new private properties.

>+.tabbrowser-arrowscrollbox > .tabs-newtab-button:not([chromedir="rtl"]),

[chromedir="ltr"] instead of :not([chromedir="rtl"])

>+.tabs-newtab-button {
>+  display: -moz-box;

This looks like a no-op.

>+.tabs-container:not([overflow="true"]) > .tabs-newtab-button {
>+  display: none;

This belongs in browser/base/content/browser.css, and I think we want visibility:collapse rather than display:none in this case.

Comment 57

[Nochum Sossonko [:Natch]]

(In reply to comment #56)
> (From update of attachment 354365 [details] [diff] [review])
> That's better, thanks!
> 
> >-            <children/>
> >+            <children includes="tab"/>
> 
> Is that change necessary?

Strangely enough, yes, the only reason I went with the first patch originally was becausethe appended tabs were showing up to the right of the new tab button, then I tried this and it worked, bug?
> >+      <field name="mTabsNewtabButton">
> 
> I think most of the time we're using _fooBar instead of mFooBar for new private
> properties.

Sure, I'll correct that
> >+.tabbrowser-arrowscrollbox > .tabs-newtab-button:not([chromedir="rtl"]),
> 
> [chromedir="ltr"] instead of :not([chromedir="rtl"])
> 
> >+.tabs-newtab-button {
> >+  display: -moz-box;
> 
> This looks like a no-op.
> >+.tabs-container:not([overflow="true"]) > .tabs-newtab-button {
> >+  display: none;
> 
> This belongs in browser/base/content/browser.css, and I think we want
> visibility:collapse rather than display:none in this case.

huh, this is in browser/base/content/browser.css.

Thanks for the review!

Comment 58

[Nochum Sossonko [:Natch]]

Comment on attachment 354365 [details] [diff] [review]
Better patch

New patch coming, gonna address the review and also add styles for pinstripe and gnomestripe.

Alex: is there supposed to be a new icon for this?

Comment 59

[Dão Gottwald [:dao]]

(In reply to comment #57)
> > >+.tabs-container:not([overflow="true"]) > .tabs-newtab-button {
> > >+  display: none;
> > 
> > This belongs in browser/base/content/browser.css, and I think we want
> > visibility:collapse rather than display:none in this case.
> 
> huh, this is in browser/base/content/browser.css.

nope, you're in browser/themes/winstripe/browser/browser.css

Comment 60

[Nochum Sossonko [:Natch]]

Attachment: Patch ver. 2.1

Here's the patch with the review comments, I didn't add anything for pinstripe/gnomestripe as I don't what needs to be added there (hard for me to tell without a mac or linux build env.)

(In reply to comment #59)
> nope, you're in browser/themes/winstripe/browser/browser.css

Ye, sorry I fixed that in this patch.

Comment 61

[Dão Gottwald [:dao]]

Comment on attachment 354420 [details] [diff] [review]
Patch ver. 2.1

>+.tabs-container:not([overflow="true"]) > .tabs-newtab-button {
>+  visibility: collapse;
>+}
>+
>+.tabs-container[overflow="true"] > .tabbrowser-arrowscrollbox > .tabs-newtab-button {
>+  visibility: collapse;
>+}

I forgot that we still have tabbrowser.css, please add this there.
And you can merge the rules: a, b { foo } instead of a { foo } b { foo }.

Comment 62

[Nochum Sossonko [:Natch]]

Attachment: Patch ver. 2.2

Done!

Comment 63

[Dão Gottwald [:dao]]

Comment on attachment 354422 [details] [diff] [review]
Patch ver. 2.2

>+            <xul:toolbarbutton class="tabs-newtab-button" anonid="tabs-newtab-button"

The anonid value seems unsuited to differentiate this new-tab button from the other one. Just remove it?

> .tabbrowser-arrowscrollbox > .scrollbutton-down,
> .tabs-newtab-button,
>-.tabs-alltabs-button {
>+.tabs-alltabs-button,
>+.tabbrowser-arrowscrollbox > .tabs-newtab-button[chromedir="rtl"] {
>   border-right-style: none;
>   -moz-border-radius-topleft: 2px;
> }

> .tabbrowser-arrowscrollbox > .scrollbutton-down[chromedir="rtl"],
>-.tabs-newtab-button[chromedir="rtl"],
>+.tabs-container > .tabs-newtab-button[chromedir="rtl"],
>+.tabbrowser-arrowscrollbox > .tabs-newtab-button[chromedir="ltr"],
> .tabs-container > stack[chromedir="rtl"] > .tabs-alltabs-button {
>   border-left-style: none;
>   border-right-style: solid;
>   -moz-border-radius-topleft: 0px;
>   -moz-border-radius-topright: 2px;
>+}

This looks wrong for rtl overflow, and for ltr the "+" doesn't stay in place between non-overflow and overflow. Just removing all the .tabs-newtab-button related stuff from the cited rules (and adding opacity:.8 to .tabs-newtab-button) is better, I think.

>+.tabs-newtab-button {
>+  width: 28px;
> }

Move this down a bit, right above ".tabs-newtab-button > .toolbarbutton-icon"...

Comment 64

[Nochum Sossonko [:Natch]]

(In reply to comment #63)
> (From update of attachment 354422 [details] [diff] [review])
> >+            <xul:toolbarbutton class="tabs-newtab-button" anonid="tabs-newtab-button"
>
> The anonid value seems unsuited to differentiate this new-tab button from the
> other one. Just remove it?

Yeah, just a remnant from a previous patch I tried doing...
> > .tabbrowser-arrowscrollbox > .scrollbutton-down,
> > .tabs-newtab-button,
> >-.tabs-alltabs-button {
> >+.tabs-alltabs-button,
> >+.tabbrowser-arrowscrollbox > .tabs-newtab-button[chromedir="rtl"] {
> >   border-right-style: none;
> >   -moz-border-radius-topleft: 2px;
> > }
> 
> > .tabbrowser-arrowscrollbox > .scrollbutton-down[chromedir="rtl"],
> >-.tabs-newtab-button[chromedir="rtl"],
> >+.tabs-container > .tabs-newtab-button[chromedir="rtl"],
> >+.tabbrowser-arrowscrollbox > .tabs-newtab-button[chromedir="ltr"],
> > .tabs-container > stack[chromedir="rtl"] > .tabs-alltabs-button {
> >   border-left-style: none;
> >   border-right-style: solid;
> >   -moz-border-radius-topleft: 0px;
> >   -moz-border-radius-topright: 2px;
> >+}
> 
> This looks wrong for rtl overflow, and for ltr the "+" doesn't stay in place
> between non-overflow and overflow. Just removing all the .tabs-newtab-button
> related stuff from the cited rules (and adding opacity:.8 to
> .tabs-newtab-button) is better, I think.

Then the button will have a border on the right side when in overflow mode and doesn't fit with the rest of those buttons that only have left borders. Then again right before overflow, when the button is touching the all-tabs button it has that look anyhow, this could be tweaked as well, but I take it you'd rather not? The rtl styles are needed though, it's backwards without it.

In general what those styles do is:

--------------------------------------------------
____________________                  ___________  
|              | + |                  |<| + |o o|
| some tab     |   |                  | |   |o o|

So the left new tab button needs a right border, but not a left border. The right new tab button needs a left border, but not a right border. For rtl it's the exact opposite.

Comment 65

[Dão Gottwald [:dao]]

(In reply to comment #64)
> Then
> again right before overflow, when the button is touching the all-tabs button it
> has that look anyhow

exactly

> this could be tweaked as well, but I take it you'd rather
> not?

Well, if you wanna give it a try, give it a try. I'm not sure how you want to address this, and I'm afraid that the result will have new rough edges.

> The rtl styles are needed though, it's backwards without it.

If there's a border on either side, what's needed for rtl?

Comment 66

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

Attachment: Details of the new tab button on windows

Here is a quick spec for how I think the button should appear in the normal and tab overflow state.  I'm using 32 pixels for the width of the normal new tab button, since this width is used in several other places in the browser chrome (larry button, search engine button), and to make the button a slightly larger hit area.

Comment 67

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

Comment on attachment 353624 [details]
Screenshot of proposed button

Looks good, but we need a few changes to the borders of the button in each position (normal, overflow), and some tweaks to the button width.  Details and mockup in comment #66.

Comment 68

[Nochum Sossonko [:Natch]]

Comment on attachment 354422 [details] [diff] [review]
Patch ver. 2.2

New patch coming...

Alex, I couldn't completely understand the mockup, particularly the border on the normal new tab button, do you want borders on both sides (including the side that touches the tabs)? By the overflow button, do you want a thicker border on the right side (the one that touches the all tabs button) or just the normal button style (as in no right border, only left border)?

Comment 69

[Frank Freibuth]

Why would we want to keep the tiny, barely usable button in its current, 18px size in the case of overflow?
I though we all agreed that the "new tab"-button is among the most important buttons, even more for people that utilize a lot of tabs and therefor experience the overflow very often. For me, and a lot of people I know, this is almost the normal condition of Firefox.
The new mock-up by Alex continues to bury the absolutely vital button between two far less important ones in that case. I think it is more important to make it an easy to find and easy to click target than making all buttons the same size in a misguided attempt to create a "clean" interface.
32px is still rather small, but I could live with that, keep the button at least this big in all scenarios. Maybe make it stick out even more instead of trying to hide it away.
"New Tab" is not as important as "List all tabs", it is much more important and we could simultaneously show that and make it significantly easier to use if we DON'T make it the same size. Make it twice the size ... 36px sounds good to me, but 32px wouldn't look out of place either.

Comment 70

[Nochum Sossonko [:Natch]]

Attachment: Patch ver. 2.3

Comment 71

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #69)
> I though we all agreed that the "new tab"-button is among the most important

You were wrong. There is nothing about the new tab button that makes it more important than other buttons, and once a user has gotten to the point where they've filled their tabstrip, we can assume that we're dealing with a user who's comfortable and familiar with tabbed browsing. The progression of the new tab button along the strip is logical and will clearly communicate to users where this functionality has gone.

Comment 72

[Frank Freibuth]

For all the users that were comfortable with tabbed browsing we did the following to the current incarnation of the "new tab" in this release:

* shrunk the button by about 75% (!)
* removed customizability
* put it in a completely different position and buried it between two other tiny buttons
* basically destroyed it as the drag and drop zone it has been since 1.5 (it still technically works but more by accident than by design and a 18px dropzone is about as useful as none at all)

If that isn't a regression I don't know what is.
There has to be something about the "new tab" button that makes it more important than e.g. "list all tabs" since basically all other browser massively overhauled it and made it more prominent and easy to use in their recent releases. Not a single one of those even considers grouping it with other buttons or shrinking it in case of overflow.
Firefox 3.1 is the odd one out that actually made it harder to use for all veteran users. I do believe that the current change is in its core a good one: The "new tab" belongs on the tab bar, I just wholeheartedly disagree with its current design. If we can't come up with a better solution to its placement than Chrome, IE and Opera than we should at least copy it well and not screw up in the details.
Giving the "new tab" button constant size of 32px even in case of overflow will not interfere with the design in a way that would justify making it such a hard to click target or nearly impossible to use dropzone.

Comment 73

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

An important consideration is if the user is going to interaction with the mouse or the keyboard after they click this button.  Previously control-t was more efficient (albeit really hard to discover) since the user's next action was likely to be typing in a new location in the location bar.  Your hands start on the keyboard, and stay on the keyboard.  One of the reasons the new tab button in chrome works so well is that your hand starts on the mouse to click the new tab button, and then continues on the mouse as you interact with the information they have placed on the new tab page.  Since the changes to the new tab page are not going to make it for 3.1, the only remaining reason to have this button is so that users know that it is possible to create a new tab (single tab users).

>If we can't come up with a better solution to its placement
>than Chrome, IE and Opera than we should at least copy it well and not screw up
>in the details.

Chrome has a 28x16 target area, and doesn't do any form of tab overflow.  IE is 30x26 and places toolbar controls on the tab strip.  How exactly do you feel our implementation is inferior, just the smaller size in overflow mode to match the surrounding buttons?

I agree that we need to address the lack of customization, not just for this but for a lot of other things as well.

Comment 74

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

>Alex, I couldn't completely understand the mockup, particularly the border on
>the normal new tab button, do you want borders on both sides (including the
>side that touches the tabs)? By the overflow button, do you want a thicker
>border on the right side (the one that touches the all tabs button) or just the
>normal button style (as in no right border, only left border)?

Sorry about the confusion, for the normal state, I would like the tab button to look just like a small tab, with borders on all three sides.  For the overflow state, I would like it to match the appearance of the other buttons, with borders on the top and left.  In the case of OS X overflow buttons just have a single vertical line etch between them.

If I'm still having trouble explaining the appearance, I can try to look into how our tabs are currently implemented to be completely specific.

Comment 75

[Nochum Sossonko [:Natch]]

Comment on attachment 354913 [details] [diff] [review]
Patch ver. 2.3

great, gotta fix the small button. ;)

Comment 76

[Nochum Sossonko [:Natch]]

Attachment: Patch ver. 2.4

Hopefully the last... ;)

I changed the width on the left new tab button to an attribute on the actual xul element to avoid having to explicitly style in every browser.css. I also left the right new tab button completely unchanged. This patch also removes the anonid attr. from the right new tab button.

Comment 77

[Dão Gottwald [:dao]]

Comment on attachment 355002 [details] [diff] [review]
Patch ver. 2.4

>+            <xul:toolbarbutton class="tabs-newtab-button" width="32"

That part was better in the previous patch. The width of the button should be entirely under the control of the theme.

>-          <xul:toolbarbutton class="tabs-newtab-button" anonid="newtab-button"
>+          <xul:toolbarbutton class="tabs-newtab-button"

That anonid is actually used in tabbrowser.xml.

Comment 78

[Nochum Sossonko [:Natch]]

Attachment: Patch ver. 2.5

Ok I put the anonid back and put the width in the styles. I also added styles for pinstripe and gnomestripe, although I'm not sure exactly what's needed for them. At least for pinstripe, I don't think it makes sense for the new tab button to look like a tab, so I just added width and padding to the styles. For gnomestripe, I can't really tell what's needed, so I just added the width.

Comment 79

[Frank Freibuth]

(In reply to comment #73)
> Since the changes to the
> new tab page are not going to make it for 3.1, the only remaining reason to
> have this button is so that users know that it is possible to create a new tab
> (single tab users).

These changes will eventually make it into Firefox and similar functions are already possible via widely used extensions. I was hoping that the "new tab" button could already be done RIGHT in preparation for the new features in future versions and that does include making it as easy to use as possible and prepare for its massively enhanced significance. Or do you intend to change its size and position with every new version of the browser?


> Chrome has a 28x16 target area, and doesn't do any form of tab overflow.  IE is
> 30x26 and places toolbar controls on the tab strip.  How exactly do you feel
> our implementation is inferior, just the smaller size in overflow mode to match
> the surrounding buttons?

Yes, 14px makes a difference between night and day on an otherwise 32px wide button, squeezing this smaller version between two far less important buttons makes it feel like this button was designed to be as hard to use as possible and certainly not as important as it is already and as it is going to be in future versions.

Everybody keeps ignoring that for many veteran users of Firefox the button has also been a dropzone for all kinds of things: Non-clickable text-links, regular links on system without a third mouse button, texts for "I'm feeling lucky" searches or even currently open tabs in order to duplicate them. These features were completely intuitive and very helpful and made the old tab-button vastly superior to the ones of the competition, even if it weren't there by default and couldn't even be moved to a more natural position (i.e. onto the tab-bar)
This has been completely ignored in the efforts to redesign this button. Tab-duplication via drag and drop is now impossible, other features are only possible by accident since the whole tabbar is kind of a dropzone with similar attributes.
I keep struggling with getting used to this regression and feature-loss as I try to keep dragging things onto a now almost ridiculously tiny target, both in height and in width.

I am convinced that the "new tab" redesign, while certainly necessary, is fundamentally flawed in its current form since its current and future significance is quite obviously massively underestimated. While certainly not representative I feel that almost everybody I discussed this with outside of the bugzilla platform agrees with me on that. Simply increasing its size or at least its width under all circumstances would at least remedy some of the problems I see with it.

Comment 80

[Nochum Sossonko [:Natch]]

The "tab duplication" requires bringing back some of the code from the old button, the new button doesn't have any drag/drop events associated with it.

Comment 81

[Frank Freibuth]

This doesn't sound like too much or too risky work if I'm not mistaken (add events, use small parts of the old, existing code for them) and I would file a bug, but there really isn't any point if the button is going to stay at the size currently intended, at just 18px it's practically useless as a dropzone.

Comment 82

[Nochum Sossonko [:Natch]]

IMHO this patch should be taken together with the patch in bug 456984 attachment 340488 [details] [diff] [review] as an interim solution until bug 457187 is taken (probably next release), but devs don't seem to agree. It is a bit redundant to have two new tab buttons, but without support for customization I think that's the only solution (the "old" button should probably be left out by default, but available for those that want it. Maybe there could even be a hidden pref to hide the "new" button to circumvent the redundancy.

Comment 83

[Frank Freibuth]

I don't think that having two badly designed "new tab" buttons is better than having only one. I can live without the customizability for a while and the new location is basically fine ... but if we go with the new button it is so much more important to do it right. It can't lose features left and right (the old drop-events have to be re-added) and it can't be as minuscule as currently planned. If we can't get it right for 3.1 than the new "new tab" button should be backed out.

Comment 84

[Dão Gottwald [:dao]]

Comment on attachment 355047 [details] [diff] [review]
Patch ver. 2.5

browser/themes/winstripe/browser/browser.css:

> +.tabbrowser-arrowscrollbox > .tabs-newtab-button {
> +  width: 32px;
> +  -moz-padding-start: 2px;

Remove that -moz-padding-start along with -moz-margin-end: 2px; from .tabs-newtab-button > .toolbarbutton-icon.

> +  -moz-border-radius-topright: 2px;
> +  -moz-border-radius-topleft: 2px;
> +  -moz-border-right-colors: ThreeDShadow rgba(255,255,255,.3);
> +}
> +
> +.tabbrowser-arrowscrollbox > .tabs-newtab-button:hover {
> +  -moz-border-right-colors: ThreeDShadow transparent;
>  }

The -moz-border-right-colors don't work, as the border width is still 1px. It doesn't even look right with the width set to 2px, so just remove these colors.

The empty label can shift the icon. To prevent this, please add this to tabbrowser.css:

.tabs-newtab-button > .toolbarbutton-text {
  display: none;
}

Comment 85

[Dão Gottwald [:dao]]

I think you can remove width: 32px; from pinstripe, as the padding should already do the same.

Comment 86

[Nochum Sossonko [:Natch]]

(In reply to comment #84)
> (From update of attachment 355047 [details] [diff] [review])
> browser/themes/winstripe/browser/browser.css:
> 
> > +.tabbrowser-arrowscrollbox > .tabs-newtab-button {
> > +  width: 32px;
> > +  -moz-padding-start: 2px;
> 
> Remove that -moz-padding-start along with -moz-margin-end: 2px; from
> .tabs-newtab-button > .toolbarbutton-icon.
The button needs padding to center the image, do you want me to just style it with -moz-padding-start (i.e. left button 9px, right button 2px). Is that how you want me to do it, or did you have something else in mind.

>The empty label can shift the icon. To prevent this, please add this to
>tabbrowser.css:
>
>.tabs-newtab-button > .toolbarbutton-text {
>  display: none;
>}
All the themes already style it like that (besides gnomestripe which has some margins going on) so I moved it to tabbrowser.css, although I'm not sure what to do with gnomestripe's margin styles.

Comment 87

[Dão Gottwald [:dao]]

(In reply to comment #86)
> The button needs padding to center the image

I don't think so... As a toolbarbutton it has -moz-box-pack: center and -moz-box-align: center.

> All the themes already style it like that (besides gnomestripe which has some
> margins going on) so I moved it to tabbrowser.css, although I'm not sure what
> to do with gnomestripe's margin styles.

With the label being hidden, there's nothing left to do for gnomestripe.

Comment 88

[Nochum Sossonko [:Natch]]

Attachment: Patch ver. 2.6

Hope I got it right this time. The centering problem I was having was just my own fault (I moved the toolbarbutton-text style to tabbrowser.css and forgot to make in browser/base). This addresses everything from the previous comments.

Comment 89

[Dão Gottwald [:dao]]

Comment on attachment 355145 [details] [diff] [review]
Patch ver. 2.6

Thanks!

Comment 90

[Nochum Sossonko [:Natch]]

Out of curiosity, why was the -moz-margin-end style there to begin with?

Comment 91

[Nochum Sossonko [:Natch]]

Attachment: screenshot

Here's the screenshot of the regular button and the overflow button (regular button on top, overflow on botton).

Comment 92

[Dão Gottwald [:dao]]

(In reply to comment #90)
> Out of curiosity, why was the -moz-margin-end style there to begin with?

To compensate the left border or so, which isn't really necessary. I guess I was testing wrongly.

Comment 93

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

Comment on attachment 355145 [details] [diff] [review]
Patch ver. 2.6

Didn't have time to test the patch to see how the hover states are behaving, but the screenshot looks good.

Comment 94

[Pardal Freudenthal (:ShareBird)]

Sorry if this is considerate as spam, but there is already an extension: New Tab Button on Tab Right - https://addons.mozilla.org/en-US/firefox/addon/5338 which implements this with a high level of customization: you can put the new tab button on the right end of the tabbar, left end of the tabbar or right side of the last tab. Making a section on "Options Window - Tabs" to handle customization for the tabbar (including options for hide the tabbar if only one tab is open, include close button at the tabbar or not, both now hidden preferences, and options for the new tab button) could solve possible complains about this. Just my two cents...

Comment 95

[Tyler Downer [He/Him]]

having an extension is nice, but that does not change the status of this bug. The patch has received review +, so it just needs to be checked in now.

Comment 96

[Nochum Sossonko [:Natch]]

gavin: ping

Although this is a P2, I assume it would be nice to get in for beta 3...

Comment 97

[Jordan Gutterman]

Why isn't this a P1 since it is a major change in the primary UI that we're going to get a lot of feedback on, and is late-compat for add-ons and especially for extensions? This doesn't seem like something that sees the light of day the first time in an RC to me.

Comment 98

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 355145 [details] [diff] [review]
Patch ver. 2.6

>diff --git a/browser/base/content/tabbrowser.xml b/browser/base/content/tabbrowser.xml

>-            <children/>
>+            <children includes="tab"/>

This change worries me a lot. It will potentially cause content added by addons to be hidden. Thankfully, it appears that specifying both works around the bug just as well, and still allows other added elements to appear:

            <children includes="tab"/>
            <children/>

>diff --git a/browser/themes/winstripe/browser/browser.css b/browser/themes/winstripe/browser/browser.css

>+.tabbrowser-arrowscrollbox > .tabs-newtab-button {
>+  width: 32px;
>+  -moz-border-radius-topright: 2px;
>+  -moz-border-radius-topleft: 2px;
>+}

Does this need an RTL equivalent?

Comment 99

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #97)
> Why isn't this a P1 since it is a major change in the primary UI that we're
> going to get a lot of feedback on, and is late-compat for add-ons and
> especially for extensions?

I think we should get it in the beta, yeah. I'm not sure I agree that it will have an impact on add-ons, but I've been wrong in assuming that before - do you have any examples of addons that would be affected by this change?

Comment 100

[Nochum Sossonko [:Natch]]

Attachment: final patch

Carrying forward r+ and ui-r+.

(In reply to comment #98)
> (From update of attachment 355145 [details] [diff] [review])
> >diff --git a/browser/base/content/tabbrowser.xml b/browser/base/content/tabbrowser.xml
> 
> >-            <children/>
> >+            <children includes="tab"/>
> 
> This change worries me a lot. It will potentially cause content added by addons
> to be hidden. Thankfully, it appears that specifying both works around the bug
> just as well, and still allows other added elements to appear:
> 
>             <children includes="tab"/>
>             <children/>
Done! Nice catch.
> >diff --git a/browser/themes/winstripe/browser/browser.css b/browser/themes/winstripe/browser/browser.css
> 
> >+.tabbrowser-arrowscrollbox > .tabs-newtab-button {
> >+  width: 32px;
> >+  -moz-border-radius-topright: 2px;
> >+  -moz-border-radius-topleft: 2px;
> >+}
> 
> Does this need an RTL equivalent?

No because we're specifying that _both_ corners should be rounded. This is for the tabbar newtab button.

Comment 101

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #100)
> >             <children includes="tab"/>
> >             <children/>
> Done! Nice catch.

Actually we should probably also add a comment explaining why we're doing that, referring to the XBL bug you filed (don't recall the bug # offhand).

> No because we're specifying that _both_ corners should be rounded

Doh! Failed to notice that...

Comment 102

[Nochum Sossonko [:Natch]]

Attachment: final final patch

Ok, now with comment.

Comment 103

[Nochum Sossonko [:Natch]]

Attachment: final final patch

Sorry that was the wrong patch :)

Comment 104

[Ed Lee :Mardak]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1d421445cdfa

Still needs to land on trunk.

Comment 105

[Ed Lee :Mardak]

Attachment: 1.9.1 patch

There were some conflicts for 1.9.1 (USE_TAB_PREVIEWS stuff).

Btw, no need to carry over r+, ui+, etc.

Comment 106

[Ed Lee :Mardak]

http://hg.mozilla.org/mozilla-central/rev/8d6830999439

Comment 107

[ojab]

Looks like regression: https://bugzilla.mozilla.org/show_bug.cgi?id=474964

Comment 108

[Mike Beltzner [:beltzner, not reading bugmail]]

Also looks pretty wrong on OSX: http://www.grabup.com/uploads/2dad5f503faa877973327a7e8f9cd0c2.png

Comment 109

[Oakwine]

(In reply to comment #108)
> Also looks pretty wrong on OSX:
> http://www.grabup.com/uploads/2dad5f503faa877973327a7e8f9cd0c2.png

In December, I filed Bug 468839 - "Open a new tab" button should be black, not blue, in Mac theme.  I think that covers the issue?

Comment 110

[Hideo Oshima]

New Tab button is still right side of tab bar in my environment.
Isn't this fix applied for Linux?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090123 Minefield/3.2a1pre

Comment 111

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

The button hasn't been themed on OS X yet, it will get a new icon and the appearance of being a background tab (albeit shorter), similar to windows.

Comment 112

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified on trunk and 1.9.1 with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090125 Shiretoko/3.1b3pre (.NET CLR 3.5.30729) ID:20090125052901

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090126 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090126020313

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090125 Minefield/3.2a1pre ID:20090125034316

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090126 Minefield/3.2a1pre ID:20090126020316

Comment 113

[Hideo Oshima]

(In reply to comment #110)
> New Tab button is still right side of tab bar in my environment.
> Isn't this fix applied for Linux?
> 
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090123
> Minefield/3.2a1pre

I filed bug 475327.

Comment 114

[Marc Auslander]

Just saw this change, and I HATE it!

For sake of honesty, I never use the new tab button anyway.  ctrl-t or middle click are just fine, as far as I'm concerned.

But having it sit right next to the close tab button for the rightmost tab is just plain wrong, IMHO.  Besides being an eyesore, it just cries out for being clicked by mistake.

Please make this optional if you must do it.

Comment 115

[Tyler Downer [He/Him]]

Marc,
there is a separate bug on making the new tab button customizable.

Comment 116

[Chris Ilias [:cilias]]

user-doc-complete
<https://support.mozilla.com/kb/Tabbed+browsing?bl=n>

Comment 117

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This is covered by Litmus:
https://litmus.mozilla.org/show_test.cgi?id=8086