"New Tab" Customizable Button Needs to Be Added Back

VERIFIED FIXED in Firefox 3.6a1

Status

()

Firefox
Toolbars and Customization
P1
normal
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: John, Assigned: Natch)

Tracking

({addon-compat, verified1.9.1})

3.5 Branch
Firefox 3.6a1
addon-compat, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3.5 +
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [stop-gap for 3.1 only], URL)

Attachments

(6 attachments, 8 obsolete attachments)

15.81 KB, patch
Details | Diff | Splinter Review
2.97 KB, application/x-xpinstall
Details
6.14 KB, patch
Gavin
: review+
Details | Diff | Splinter Review
8.01 KB, patch
Gavin
: review+
Details | Diff | Splinter Review
6.15 KB, patch
Details | Diff | Splinter Review
8.96 KB, image/png
Details
(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080925033548 Minefield/3.1b1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080925033548 Minefield/3.1b1pre

Because of Bug 455756, a the new tab button was added to the tab bar. However, some users do not display the tab bar by default when there is only one page open. As a result, there is no button to click on to create a new tab. We know about Control-T, but that's not the point. 

There is no option to add a new tab button to the other toolbars.



Reproducible: Always

Steps to Reproduce:
1. Right click and customize the toolbars.

Actual Results:  
The customizable new tab button is missing

Expected Results:  
The customizable new tab button should be available

This feature was around since before Firefox 1. The fact that it disappeared in less than a week is outrageous. It better have been a mistake and not intentional.
(Reporter)

Updated

10 years ago
Depends on: 455756

Comment 1

10 years ago
The tabbar is shown by default now.
(Reporter)

Comment 2

10 years ago
But there's an option to hide it. Then there's no way to get a new tab button.

Comment 3

10 years ago
(In reply to comment #2)
> But there's an option to hide it.

Bug 455864 is going to degrade that to a hidden pref.

Updated

10 years ago
Depends on: 455864
(Reporter)

Comment 4

10 years ago
After reading Bug 455864, you might as well mark this as invalid, because if the option to hide the tab bar is made hidden and the button will not be added to customize other menus, the argument is over. 

It seems that Mozilla has some ideas for a better UI with the tab bar visible all times. I trust you guys in the long run, but this change was very quick and unexpected. I need to get used to it.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

10 years ago
I agree that the developers should restore the freedom users have had for years in being able to drag and drop toolbar buttons such as this back.  The fixed state of the new tab button isn't even user friendly!  At least Microsoft got that right and put it right next to the last tab!!!  Now I have to either Ctrl-T or drag my mouse all the way over to that fixed button, and believe me on a large wide screen it's now a pain.  It's small things like this that really drive users away.

~B
(Reporter)

Comment 6

10 years ago
This is really bad for widescreen users. I have one. It's out of the way. And I can't see the immediate benefit of having the tab bar open all the time. I can;t get used to it.
making the tab bar always visible by default is *no* reason to drop the new tab button in total, despite of what Bug 455864 says.

my user case:
i have set up my toolbar buttons like this:
http://img257.imageshack.us/img257/2254/bug456984ze5.png
with the change of Bug 455756 the "mouse way" of opening new tabs is way too far from locationbar *and* the other toolbar buttons where the other chrome actions happen (reload, stop, entering new url).
i wouldn't call this new behavior very efficient.

proposal:
- change of Bug 455756 is default
- make the new tab button available again in the customization panel
- if a users drags the button to *any* toolbar, hide the newly introduced button on the tabstrip (since i see no point to have them both in UI at the same time)
Severity: major → normal
Flags: blocking-firefox3.1?
Keywords: uiwanted
Version: unspecified → Trunk

Comment 8

10 years ago
There isn't much reason the navbar button needed to go away. It wasn't on by default, but was a customization for users who preferred that method. I'm all in favor of that button on the tabbar for new users, it's been needed since somewhere around the day after we got a tab bar, and it's good to have. BUT, this isn't a situation where we need a pref for choosing a codepath here. This is a case where the old functionality was merely being duplicated in a new button in a more discoverable place. That doesn't mean that we have to kill the old button. It decreases a user's out of the box customization choices for no valid reason. It's not a physical object we only have one of and thus it can only be in once place.

Comment 10

10 years ago
I was just about to make 3 different bugs nominated for blocking out of this:

1) As stated in this bug, not all users will have tab bar set to visible and so it makes it impossible to see with 1 window.

2) It removes a customisable part of the UI and replaces it with a static one, users will be rightfully annoyed and frustrated with this!

3) It places an "open new tab" button right next to the "close last tab on the bar", which makes it painful for users, especially give a lot don't know about History > Undo Close Tab.

Is there development agreement on these issues or should I make spin-off bugs?
(In reply to comment #5)
> I agree that the developers should restore the freedom users have had for years
> in being able to drag and drop toolbar buttons such as this back.  The fixed
> state of the new tab button isn't even user friendly!  At least Microsoft got
> that right and put it right next to the last tab!!!  Now I have to either
> Ctrl-T or drag my mouse all the way over to that fixed button, and believe me
> on a large wide screen it's now a pain.  It's small things like this that
> really drive users away.

Oh, I don't know. You've been threatening to leave as long as I've been involved in the project and you're still around.

When Dao asked me if we should remove the existing new tab button, I said that I couldn't see why people would want two buttons and so gave him the nod to yank it. People here have made some convincing arguments for: 

 a) wanting it to be on the navbar instead of the tab strip
 b) wanting it to be on the left instead of the right of the tab strip
 c) wanting it to not be anywhere at all

I think that this bug, as expressed in the title and comment 0, won't properly address any of those points. The correct solution would be to make the new "new tab" button draggable, such that it can be placed at the left or right of the tab strip, on the nav bar, or removed entirely. The current default placement and location is correct. This either requires a bugmorph (reporter can decide to do that) or a spinoff bug.
(In reply to comment #11)
[...]
> People here have made some convincing arguments for: 
> 
>  a) wanting it to be on the navbar instead of the tab strip
>  b) wanting it to be on the left instead of the right of the tab strip
>  c) wanting it to not be anywhere at all
> 
> I think that this bug, as expressed in the title and comment 0, won't properly
> address any of those points. The correct solution would be to make the new "new
> tab" button draggable, such that it can be placed at the left or right of the
> tab strip, on the nav bar, or removed entirely. The current default placement
> and location is correct. This either requires a bugmorph (reporter can decide
> to do that) or a spinoff bug.

Well, if the user can drag the button elsewhere, as desired by the current Summary and recommended by the above paragraph, then it is much less of a problem if you, or I, or the reporter, doesn't like the default placement. The above paragraph seems to point towards making the tab bar one more customizable toolbar, with the tabs themselves (probably as one widget, like the bookmarks on /their/ toolbar) occupying most of it. Then other buttons, such as for instance the "New Tab" button, could be placed on that "tab toolbar" or, at user's choice, dragged elsewhere, such as on some other toolbar, on the menubar, or even parked on the button palette.

Comment 13

10 years ago
Bug 457187 as per Beltzner's comments. Please mark it as duplicate of this bug if this bug gets morphed
(Reporter)

Comment 14

10 years ago
So how do I go about morphing it? Do I mark this a duplicate of Bug 457187, or should that be marked a duplicate of this (since the other bug technically will solve the issue being debated here)
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
I don't think this bug should be morphed into a different bug.
I see that bug 457187 is now created that is about being able to drag the new tab button thing (which seems like a good idea to me).

Although, perhaps comment 0, which describes this bug is perhaps the same as bug 457187. In that case, you could call this bug a duplicate of that bug. Or else, if this is about adding an extra new tab button to the "Customize.." section, then it should presumably become wontfixed.
Resolution: FIXED → WONTFIX
Flags: blocking-firefox3.1?
Created attachment 340792 [details]
extension that adds back the New Tab button

Updated

10 years ago
Depends on: 347930

Updated

10 years ago
Duplicate of this bug: 459507

Comment 18

10 years ago
All my clients have Firefox with the toolbar buttons clearly visible, large, and with text labels. They know exactly where to get everything. Now if the new tab button disappears I'm going to have several hundred disgruntled people calling me asking why their buttons disappeared.

Personally I use both GUI and the keyboard...whatever requires the least thinking so I can concentrate on the task at hand. Minimal thought, not minimal GUI: that is how good design works. Isn't there an extension for this morphed version of the button? Why aren't IMPORTANT bugs like 405461, 383349, 423014, and 295977 being fixed?

Now I have to move my mouse 1800 pixels to the right side of the screen instead of 200. Wasn't a customizable GUI the whole point of Firefox to begin with? We don't even have a Go button any more...I have to manually create and edit a file to display it. I click the go button dozens of times a day and bookmark a page once a month...so why would we add to this counter-intuitive design and statically move the new tab button (without any text label and no roll-over titles don't count for squat for normal users who do light computing) that absolutely has to be located at the far right of my 24 inch screen? This is all horrible design which is one of the major reasons why people are rejecting Vista in example.

My tab bar is always set to display as well as my clients. They nor should I be expected to pres CTRL+T, double click, or "get used to" clicking on a little green plus arrow for something of such great significance. That is the beauty of customizability: whatever is easiest works and helps keep you productive. A counter-intuitive design will aggravate people, start requiring extra thinking for what should be a thoughtless action on the user's account, and ultimately turn people away. Plus why would the new tab button be removed but we can still add the new window button? 

Also to the OP of the bug, please (like every other bug report I've EVER made here) please consider what other people may search for before posting a bug report. The button was missing at some point in the nightly builds. I recommend using the REACTION as the title and the request as part of the expected textarea. If people start doing this more there would be fewer duplicate bugs.

Comment 19

10 years ago
John A. Bilicki III please see bug 457187 and also bug 347930 if both of these make 3.1 (and the former will have to if the latter does) then the Firefox GUI will be more customizable in regards to tabs and the new tab button, not less.
Duplicate of this bug: 459877
(Assignee)

Updated

10 years ago
Keywords: uiwanted

Comment 21

10 years ago
Reopening per Alex's comment at <http://groups.google.com/group/mozilla.dev.apps.firefox/msg/afb2641b2f53752d>:

1. Re-add a New Tab button to the toolbar palette.
2. Hide the new button on the tab bar whenever that button has been manually added.

Bonus points for reverting the IDs so that people already having customized their toolbars to show that button won't notice any difference.

This shall be a stop-gap measure until bug 347930 is fixed.

A reminder to everybody not contributing code: Please don't comment here but rather answer to Alex's post in the newsgroup!
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Whiteboard: [don't comment unless you contribute code][stop-gap for 3.1 only]
Version: Trunk → 3.1 Branch

Updated

10 years ago
Keywords: late-compat, late-l10n
Flags: blocking-firefox3.1?

Updated

10 years ago
Duplicate of this bug: 472642
(Assignee)

Comment 23

10 years ago
Why is this late-compat and late-l10n, IMO we should use the same labels and tooltips as the other button. Removing dependency on bug 347930 as that is the long-term solution which will obsolete this bug, hence this is not dependent on that fix.
No longer depends on: 347930
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P2
(Assignee)

Comment 24

10 years ago
Created attachment 356892 [details] [diff] [review]
Hacky patch

This is a hacky patch to restore the old button and make the new button disappear when the old one is in use. This applies on top of the patch in bug 457651.
Attachment #356892 - Flags: review?(gavin.sharp)
Comment on attachment 356892 [details] [diff] [review]
Hacky patch

Attribute names are usually lowercase.

#navigator-toolbox isn't in the scope of tabbrowser.css (see e.g. bug 404229 comment 6).
I think I'd call the attribute "hidenewtabbutton" (or something similar) and set it on gBrowser.
(Assignee)

Comment 27

10 years ago
(In reply to comment #25)
> (From update of attachment 356892 [details] [diff] [review])
> Attribute names are usually lowercase.

Yeah, sorry about that, I'm just so used to that style...

> #navigator-toolbox isn't in the scope of tabbrowser.css (see e.g. bug 404229
> comment 6).

Can I put this in browser.css? I need to use #navigator-toolbox because it's reachable from the toolbox code, although I'll look into it later tonight. Also the attribute indicates whether the tab button is in the palette or not, in other words: true means it's *not* on the toolbar, rather in the palette.
Status: REOPENED → NEW
We shouldn't touch customizeToolbar.js for this (unless a new generic hook is needed). BrowserToolboxCustomizeChange might be what you're looking for.
(Assignee)

Comment 29

10 years ago
Comment on attachment 356892 [details] [diff] [review]
Hacky patch

Hrm, you're right I should probably just use BrowserToolboCustomizeDone, and it would be much easier to do it there. Although, can I put them in browser/content/browser.css instead of in each theme?
Attachment #356892 - Attachment is obsolete: true
Attachment #356892 - Flags: review?(gavin.sharp)
If you set the attribute on gBrowser, using tabbrowser.css should be fine.
Natch - it looks like you are working on this, so I'm assigning it to you since this shows up as an unowned blocker currently.
Assignee: nobody → highmind63
Keywords: late-l10n
(Assignee)

Updated

10 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 32

10 years ago
Created attachment 357053 [details] [diff] [review]
Patch ver. 2

Ok, this patch addresses the previous comments in a slightly different manner. What do you think of this approach? I decided to put the attribute on tabContainer because it's part of tabbrowser.xml and also enables more specific selectors instead of a general descendant selector.
Attachment #357053 - Flags: review?(dao)
(Assignee)

Updated

10 years ago
Attachment #357053 - Attachment is patch: true
Attachment #357053 - Attachment mime type: application/octet-stream → text/plain
(Assignee)

Comment 33

10 years ago
Maybe the dynamic removal of the new buttons should be excluded from the patch, it messes a little bit with the tab scrolling. Nothing major, just some cosmetic stuff, if the right-most tab is fully visible, then switching to the old button leaves a small gap (the size of the new button) between the last tab and the right arrow, vice-versa as well. Not sure how to fix that, though. Thoughts?
I know nothing about coding Mozilla, but isn't it easier to undo the revision that took new tab button away to bring it back? Why does someone need to re-write it?

Comment 35

10 years ago
(In reply to comment #34)
The actual functionality of the new tab button is kept from the previous patch. What needs to be written is the code to hide the button on the tab bar when the toolbar button is visible.
(In reply to comment #33)
> Maybe the dynamic removal of the new buttons should be excluded from the patch,
> it messes a little bit with the tab scrolling. Nothing major, just some
> cosmetic stuff, if the right-most tab is fully visible, then switching to the
> old button leaves a small gap (the size of the new button) between the last tab
> and the right arrow, vice-versa as well. Not sure how to fix that, though.
> Thoughts?

gBrowser.tabContainer.adjustTabstrip(), gBrowser.tabContainer._fillTrailingGap() and gBrowser.tabContainer._handleTabSelect() can be utilized.
Comment on attachment 357053 [details] [diff] [review]
Patch ver. 2

>@@ -3268,6 +3307,8 @@ function BrowserToolboxCustomizeDone(aTo
>         document.getElementById('Browser:Back').hasAttribute('disabled') &&
>         document.getElementById('Browser:Forward').hasAttribute('disabled');
> 
>+    var newTabButton = document.getElementById("new-tab-button");
>+    gBrowser.mTabContainer.setAttribute("hidenewtabbutton", newTabButton ? true : false);

any reason why this isn't in BrowserToolboxCustomizeChange?
(Assignee)

Comment 38

10 years ago
I put it in BrowserToolboxCustomizeDone because it seems the rest of the ui is refreshed then, if you want it in BrowserToolboxCustomizeChange I can move it there. adjustTabstrip doesn't seem like it would do anything for me, and in my tests it hasn't really done much, although I should probably call it after the other methods to reset the [x] buttons. fillTrailingGap should work for the extra empty space, and I'll try the handleTabSelect, thanks.
(Assignee)

Updated

10 years ago
Depends on: 473745
(Assignee)

Comment 39

10 years ago
Created attachment 357280 [details] [diff] [review]
Patch ver. 3

This better? The ui is now perfect, no trailing gaps and no hidden tabs.
Attachment #357053 - Attachment is obsolete: true
Attachment #357280 - Flags: review?(dao)
Attachment #357053 - Flags: review?(dao)
(Assignee)

Comment 40

10 years ago
Created attachment 357284 [details] [diff] [review]
for real now...

Sorry about that, patch got messed up somehow, thanks goes to bugzilla interdiff!
Attachment #357280 - Attachment is obsolete: true
Attachment #357284 - Flags: review?(dao)
Attachment #357280 - Flags: review?(dao)
Comment on attachment 357284 [details] [diff] [review]
for real now...

>+//XXX Remove this post-3.1, used to show/hide the new tab button on the tab bar

Not really a useful comment, since we can't just remove it post-3.1.

>+function BrowserSetNewtabButton() {

Call this toggleTabstripNewTabButton, showHideTabstripNewTabButton or something like that.

>+  var newTabButton = document.getElementById("new-tab-button");
>+  if (newTabButton) {

if (document.getElementById("new-tab-button")) {

>+    gBrowser.mTabContainer.setAttribute("hidenewtabbutton", false);

Just remove the attribute, and use tabContainer rather than mTabContainer.

>+++ b/browser/base/content/tabbrowser.xml
@@ -127,6 +127,7 @@
>                     setfocus="false"
>                     onclick="this.parentNode.parentNode.parentNode.onTabClick(event);"
>                     xbl:inherits="onnewtab"
>+                    hidenewtabbutton="false"

that's unneeded

>+/* customizable new tab button */

"toolbar new tab button"?

>+/* customizable new tab button */

"tabstrip new tab button"?
(In reply to comment #41)
> >+/* customizable new tab button */
> 
> "tabstrip new tab button"?

This should refer to:

>+/* fixed new tab button */
(Assignee)

Comment 43

10 years ago
Created attachment 357292 [details] [diff] [review]
Adress Comments

Done.
Attachment #357284 - Attachment is obsolete: true
Attachment #357292 - Flags: review?(dao)
Attachment #357284 - Flags: review?(dao)
(In reply to comment #38)
> I put it in BrowserToolboxCustomizeDone because it seems the rest of the ui is
> refreshed then, if you want it in BrowserToolboxCustomizeChange I can move it
> there.

Yes, please... There's no reason not to update the tab bar immediately when adding/removing the new tab button, as far as I can see.

You can also remove "XXX" from the comment in the latest patch, as it doesn't describe buggy behaviour.
(Assignee)

Comment 45

10 years ago
Created attachment 357303 [details] [diff] [review]
Patch ver. 3

Nits nixed!
Attachment #357292 - Attachment is obsolete: true
Attachment #357303 - Flags: review?(dao)
Attachment #357292 - Flags: review?(dao)
Comment on attachment 357303 [details] [diff] [review]
Patch ver. 3

While you're at it, you might want to fix the curly brackets and indent the function bodies properly:

+var newTabButtonObserver = {
+  onDragOver: function(aEvent, aFlavour, aDragSession)
+    {
+      var statusTextFld = document.getElementById("statusbar-display");
...
Attachment #357303 - Flags: review?(dao) → review+

Updated

10 years ago
Depends on: 457651
(Assignee)

Comment 47

10 years ago
The newWindowButtonObserver looks the same to me, although the other observers are somewhat different, should I change them all to be consistent? Or maybe you mean something else...

Seems like styling conventions in browser.js are somewhat inconsistent.
"var statusTextFld" is indented too far, and the curly bracket before it is on the wrong line. newWindowButtonObserver is indented oddly as well, but you shouldn't touch that here.
Comment on attachment 357303 [details] [diff] [review]
Patch ver. 3

Discussed this with beltzner and mconnor on IRC. Consensus was that the auto-hide behavior wasn't ideal, and that the ideal state for post-3.1 was to just fix bug 347930/bug 457187. That means for that for now (3.1), let's keep this bug simple and just restore the button as a customization option, letting users keep/add the old button in addition to the new one. That should also avoid the need to break string freeze.

Natch, do you want to patch that?
Attachment #357303 - Flags: review-
(In reply to comment #49)
> auto-hide behavior wasn't ideal, [...] That should also
> avoid the need to break string freeze.

Seems entirely unrelated.
Oops, yes, you're right. We'll have to add the strings back either way.
(Assignee)

Comment 52

10 years ago
Created attachment 357523 [details] [diff] [review]
bring it back

Alright, this should do it. :/
Attachment #357303 - Attachment is obsolete: true
Attachment #357523 - Flags: review?(gavin.sharp)
(Assignee)

Updated

10 years ago
No longer depends on: 473745
(Assignee)

Comment 53

10 years ago
Created attachment 357524 [details] [diff] [review]
bring it back -- indent fix

Sorry about that, I forgot to fix the indentation, same patch with the indentation fixed.
Attachment #357523 - Attachment is obsolete: true
Attachment #357524 - Flags: review?(gavin.sharp)
Attachment #357523 - Flags: review?(gavin.sharp)

Updated

10 years ago
Keywords: late-l10n

Updated

10 years ago
Whiteboard: [don't comment unless you contribute code][stop-gap for 3.1 only] → [don't comment unless you contribute code][stop-gap for 3.1 only][missed string freeze]
Comment on attachment 357524 [details] [diff] [review]
bring it back -- indent fix

Why do we need to bring the string back as opposed to doubling up from the other new tab button? I'm loathe to risk the l10n impact here ...
One of the strings is what appears in the status bar when you're dragging something over the new tab button - there is no suitable alternate for it already in the tree. The other is the same string as the existing new tab button, but would require us including tabbrowser.dtd in browser.xul if we wanted to use it.

We could probably live with just not having status bar hover text and adding the extra include if we really wanted to avoid making any l10n changes, but it looks like we're going to have to break string freeze for bug 380852 anyways, and the incremental cost of adding these two strings as well is low enough that it'd be worth doing here, I think.

Comment 56

10 years ago
I don't necessarily see bug 380852 breaking string freeze. I don't see me taking incremental arguments either, but rather see each string freeze break make a stand for its own.
(In reply to comment #55)
> One of the strings is what appears in the status bar when you're dragging
> something over the new tab button - there is no suitable alternate for it
> already in the tree. The other is the same string as the existing new tab
> button, but would require us including tabbrowser.dtd in browser.xul if we
> wanted to use it.

Can we get the patch in without string changes now (I'm even happy not having a tooltip for the button; honest) and file a follow-up to land the string changes after beta 3 but before rc1?

> the extra include if we really wanted to avoid making any l10n changes, but it
> looks like we're going to have to break string freeze for bug 380852 anyways,

I agree with Axel, fwiw, that bug 380852 isn't worth breaking string freeze pre-b3. That's another one we should and can take between b3 and rc1.
Comment on attachment 357524 [details] [diff] [review]
bring it back -- indent fix

This looks good, but is missing the gnomestripe theme changes. With those restored (reveral of the gnomestripe removals in attachment 340241 [details] [diff] [review] should do), r=me.
Attachment #357524 - Flags: review?(gavin.sharp) → review+
Also, we still need to sort out whether we can add the new strings as-is - we might have to use the workaround I suggested in comment 55.
Priority: P2 → P1
Whiteboard: [don't comment unless you contribute code][stop-gap for 3.1 only][missed string freeze] → [stop-gap for 3.1 only][missed string freeze][needs new patch]
(Assignee)

Comment 60

10 years ago
Created attachment 358306 [details] [diff] [review]
Version without strings

I don't know what the decision will be, but unless tabbrowser.dtd is added to the list of browser.xul's dtds we can't use the string from the other new tab button. So here's a version of the patch without the strings, I'll post one with the strings shortly.
(Assignee)

Comment 61

10 years ago
Created attachment 358308 [details] [diff] [review]
Version with the strings

Here's the one with the strings.

I put the stuff in gnomestripe.css back in both patches.
(Assignee)

Updated

10 years ago
Whiteboard: [stop-gap for 3.1 only][missed string freeze][needs new patch] → [stop-gap for 3.1 only][missed string freeze]
As per comment 57, I think we should review and land attachment 358306 [details] [diff] [review] (without strings) and then file a P2 blocker follow up to take the strings after b3 from attachment 358308 [details] [diff] [review].
Attachment #357524 - Attachment is obsolete: true

Comment 63

10 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/79896d61e23f

Still needs to land on trunk.
Keywords: fixed1.9.1
Target Milestone: --- → Firefox 3.2a1

Updated

10 years ago
Blocks: 474917

Updated

10 years ago
No longer blocks: 474917
Flags: in-litmus?
Keywords: late-l10n
Whiteboard: [stop-gap for 3.1 only][missed string freeze] → [stop-gap for 3.1 only]

Updated

10 years ago
Blocks: 474917

Comment 64

10 years ago
Created attachment 358351 [details] [diff] [review]
1.9.1 patch

There were some conflicts for 1.9.1 (USE_TAB_PREVIEWS stuff).

Comment 65

10 years ago
Not sure what the whiteboard [stop-gap for 3.1 only] means... but pushed to trunk with strings.

http://hg.mozilla.org/mozilla-central/rev/32d2492bf68c
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
Created attachment 358528 [details]
Extra long tab bar

Sorry, but is this the expected behavior? As how it is working right now, the new tab button inside the tab bar is shifted to the left. Means you will get an extremely long tab bar and you aren't able to open several new tabs at once because the button is shifted each time a new tab gets opened.
(In reply to comment #66)
> Sorry, but is this the expected behavior? As how it is working right now, the
> new tab button inside the tab bar is shifted to the left. Means you will get an
> extremely long tab bar and you aren't able to open several new tabs at once
> because the button is shifted each time a new tab gets opened.
bug 475082
Duplicate of this bug: 475150
Thanks Shawn! So I can verify this fix on trunk and 1.9.1 branch with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090123 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090123033224

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

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

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre ID:20090123022451
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1

Updated

9 years ago
No longer blocks: 474917
Depends on: 474917
I've updated the following Litmus test to cover the existence of the "New Tab" button.
Flags: in-litmus? → in-litmus+
(Assignee)

Updated

9 years ago
Depends on: 475073

Updated

9 years ago
Duplicate of this bug: 480285
(Assignee)

Updated

9 years ago
Depends on: 486202
(Assignee)

Updated

9 years ago
No longer depends on: 486202
Depends on: 473745
You need to log in before you can comment on or make changes to this bug.