I've see this happen probably three times so far and I've noticed the same behavior every time. wrong tab gets closed. it should close the 2nd tab if I select it, not the first.

over to tabbed browser

I'm going to attribute it to either mouse/UI comes close to selecting close-other tabs windows or accidentally selecting that option. I'm having a hard time trying to reproduce this with 2001093008 W2K. Just tried closing first tab and had the second one close on me.. so I have no way of reproducing this.. trying to keep a hard close look at what it is I'm doing while this has "occured".

Don't know if this is a related problem or not, but sometimes when i try closing the second tab from the right-click menu, the all the tabs disappear with the page from the second tab remaining in view. However, if i use ctrl-t, all the tabs reappear with the new tab opened.

I just clicked on close other tabs on the first tab, and the second one over stayed open and the others disappeared. Two Questions: 1) is there a way to trace the code path when doing this? 2) this maybe dependent on whether the tab you are highlighting is the one focused in the browser window. i.e. does the wrong behavior depend whether the you using that tabbed page in the browser..[what would be the correct language for what I just said?]

Did you only have two tabs open at the time? I tested this with a few tabs open at a once. Bug 104381.

I had this happen with a (the?) previous nightly, but with the now-current one (2001102309) I can no longer reproduce it. Retest with current nightly.

I'd say this is very similar and probably the same behavior that I have seen in bug 104381.

this is mostly the thing I'm noticing is that XUL dialog buttons with a dotted highlight box 'range' of acceptable Mouse coordinates seems to be off for a given selection. That is what this comes down to.

I had just chosen 2nd tab 'close tab' I had mozilla in 1st tab, (also I have background tab checked, hide tab checked) first tab closed.. and what was left is the second tab (which was just a about:blank tab) So I had just gotten the behavior opposite what has to true.. Hyatt, Is there some possible Random occurence of code not getting the correct result here? with the UI mouse coordinates being incorrectly mapped to the XUL dialog coordinates? vs say keyboard arrow selection.

So I had just reproduced this problem again is what I wanted to clarify for my last comment.

We are unable to repro this, need a case that fails reliably. until then, ->future

After some experimenting, I can reproduce the effect described in comment #3 pretty reliably. Done on WinXP, build 2001112303. Steps: 1. Open several tabs in Mozilla. 2. Right-click on last tab and move mouse to the separator just above Close Tab. 3. Move mouse one pixel down. (Alternately, move mouse fast enough to get in the highlighted region without displaying movement while the region is highlighted.) 4. Click on Close Tab. --> Actual results: No effect. --> Expected results: Tab closes and focus shifts to previous tab. 5. Repeat above steps on second tab with only two tabs open. --> Actual results: Page displayed in second tab stays open but the tab selection bar is hidden. Opening a new tab reveals the original two tabs as well. --> Expected results: Second tab closes and focus shifts to first (and only remaining) tab. I've done this a good dozen or so times in a row now, so hopefully I'm not crazy.

Joe: What you are seeing might be bug 102551. I cannot reproduce this behavior on Linux build 2001112308.

Mac OSX Moz 0.9.6 BUILD ID: 2001112020 I had a similar experience. Open 2 tabs and click tab 2, bringing it into focus. Right click on tab 2. Select 'Close Tab' from context menu. Tab 1 closes and tab 2 stays visible (10% of time). Doesn't matter if tab 1 is loaded or not. I could not find a pattern. Note: My prefs are set to open new tabs behind.

I think Niklas is right. This is a dup of bug 102551 I can reproduce this bug 100% if I wait about 10 seconds between the time I right-click on the tab and when I finally pick "Close Tab"

Reassigning to new component owner.

I agree with comment 14. See my report in bug 153528 for a way to reproduce it 100% of the time.

sjungels99, if this is related to your bug 153528, can you try to reproduce it? Your one is fixed, so are the other possible duplicates. -> Good chances that this is also fixed. At least I cannot reproduce it.

WFM Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007120705 Minefield/3.0b2pre