FWIW, I wrote the current behavior on purpose.  Adding a new tab seemed like a good 
signal that the user was done closing tabs, which was the main thing the no-resize 
behavior facilitated; accordingly, it was OK to switch out of "closing tabs mode", 
and this also meant tab targets would become bigger and easier to grab/drag, which is 
an action it seemed like people might want to do shortly after tab creation.

I admit it can be a little jarring, but it didn't seem so awful to me and there were 
at least minor benefits and UI consistency wins :)

I find myself doing this: wanting to do something new, closing a bunch of tabs 
because I feel like my tabstrip has become too crufty to continue on with. So I click 
the new tab button and I get a new tab. But the new tab opens somewhere else from 
where my mouse is... or rather it quickly animates away from there. It's jarring 
considering the way the new tab button operates in other situations (the location of 
the new tab on screen is predictable based on the location of the new tab button).

(No comment was entered for this change.)

Given that we got so many subtle things right with the tab-bar, I'm being cautious on
changing the behavior (The X disappearing on small out-of-focus tabs is among my
favorite tab-feature).

However, since we use a timer-delay when removing tabs until they actually resize (to
become wider). I think we can also use a timer-delay when adding tabs too. The timer
delay should be enough for the user to visually locate the tab and start reading the
page or add other tabs (if they were opening a few tabs to hold related items). When
the delay expires, tabs should resize to their new 'comfortable' size.

RFC: I've got a working implementation of two behaviors to correct this. In both
cases, the tab insertion jump is delayed. The difference is:
(1) When adding a new tab, the new tab appears immediately under the cursor which
makes the new tab button move further to the right.
(2) When adding a new tab, the new tab appears to the left of the cursor, therefore
shrinking all tabs proportionally and keeping the new tab button under the mouse.
This allows addition of multiple tabs simply by clicking the left mouse button.

Please let me know of any reason to prefer one behavior over the other.

By "Cursor" do you mean mouse pointer? If so I don't think opening relative to the 
mouse pointer is the right way to go.

Imagine this scenario:
- open a window, and open a number of tabs so that they all shrink
- close 3 tabs from the middle of the strip. You'll still have some tabs to the left 
and to the right.

When you press Ctrl+T or click the New Tab button, the new tab will open at the _end_ 
of the tabstrip, regardless of where the mouse pointer is. This is the desired 
behavior.

All this bug is about is not forcing a resize layout when that happens.

OK, So I realize my wording was not perfect. I was referring to the mouse-pointer as
the cursor but also made the unstated assumption that it was above the
New-Tab-Button. So, effectively at the end of the tab strip.

Therefore, in both options the new tab appears at the right end of the strip. The
difference remains:
(1) The New-Tab-Button moves to the right and the new tab appears between the
rightmost tab and the new tab button.
(2) The New-Tab-Button does not move and all tabs shrink to accommodate for the added
tab.

Patch ready for review http://codereview.chromium.org/14050.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8109 

------------------------------------------------------------------------
r8109 | ben@chromium.org | 2009-01-15 11:34:28 -0800 (Thu, 15 Jan 2009) | 12 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model.cc?r1=8109&r2=8108
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_strip.cc?r1=8109&r2=8108

Fix for Issue 3258: Tabs created when tabstrip is compressed pending resize
relayout should not force resize relayout.

This is proposed solution one from the comment#5 which is to
create new tabs without resizing existing tabs unless there is
no room for the new tab.

BUG=3258

Change from Itai Danan (idanan@google.com)
Code review: http://codereview.chromium.org/14050

------------------------------------------------------------------------

(No comment was entered for this change.)

I believe this is fixed.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8496 

------------------------------------------------------------------------
r8496 | maruel@chromium.org | 2009-01-22 12:09:11 -0800 (Thu, 22 Jan 2009) | 13 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_strip.cc?r1=8496&r2=8495

(1) If you create tabs and manage to resize the window before the
pending layout occurs, you get truncated tabs (As described in
 issue 6505 ). Upon resize therefore we reset the reserved width for 
tabs.

(2) When inserting a tab as the second-to-last tab, the size
of tabs was incorrect. This lead to shriking tabs in multiple
cases (as described in issue 3258).
BUG=6505
BUG=3258

Patch contributed by Itai Danan <idanana@google.com>

------------------------------------------------------------------------

I'm sorry to tell you, but I never had this problem, but today I switched to 
2.0.159.0 and now I DO have the problem. (Windows Vista Home Premium SP1).

So the problem is not solved yet

The fix was reverted due to some regression. There is a fix for those available too 
but more testing was required and we were very close to a dev-build push.

Did you eventually resolve the regressions?

I thought I did but Ben preferred not making the change so until we have a way of 
systematically testing this.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

Area-UI-Features label replaces Area-BrowserUI label

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)