User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051216 Camino/1.0+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051216 Camino/1.0+ When you click the X to close a tab and then click (once) again right away, a new tab is created. It seems to be registering it as a double-click to open a new tab. Reproducible: Always Steps to Reproduce: 1. Click the X on a tab to close it 2. Click (once) again right away Actual Results: A new tab is created. Expected Results: A new tab should not be created until a second click is performed AFTER closing the tab with the X.

This seems to be only if you click on the outermost tab, and the tab bar stays open (i.e., you start with 3 or more tabs).

This is limited to the outermost tab, but I can repro with as few as two tabs. (Obviously, it won't work with one tab, since we disable the button in that case.) cl

See also bug 218701 Ff definitely needs option for that double-click "operism".

This is a Camino-only bug

tweaking summary for easier searching.

I have also experienced this bug in the tab scrolling patch that I am working on. Anything that is on the tab bar (for example, scroll buttons) but is not a tab (if the scroll buttons are disabled because the user cannot scroll any further in that direction) is treated as the tab bar and it responds to [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(newTab:) name:kTabBarBackgroundDoubleClickedNotification object:mTabBrowser]; in BrowserWindowControler.mm You will notice that Opera exhibits this behaviour too. Might it be possible for a notification to be send upon closing a tab and if that notification exists in the NotificationCentre, then do nothing?

Mass un-setting milestone per 1.6 roadmap. Filter on RemoveRedonkulousBuglist to remove bugspam. Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.

This tripped my personal annoyance threshold.

Comment on attachment 289045 [details] [diff] [review] fix Removing review request, since the tab rewrite will rot this. I'll re-create this after it lands.

A different approach, which works with the new tab structure. I also cleaned up cruft from the tab restructuring that I noticed while cleaning up parallel code in mouseDown:

Comment on attachment 293201 [details] [diff] [review] v2 >Index: src/browser/BrowserTabBarView.mm >+ // We get a double-click even if the first click was actually on a tab's >+ // close button, so try to make sure this was really a tab bar double-click. >+ // 6 seconds is the smallest value that's longer than the maximum system >+ // double-click speed (so that we don't punish users who click slowly). >+ int clickCount = [theEvent clickCount]; >+ if (clickCount == 1) { >+ mLastClickTime = [theEvent timestamp]; >+ } >+ else if (clickCount == 2 && ([theEvent timestamp] - mLastClickTime <= 6)) { ::GetDblTime() / 60.0 ? >+ mLastClickTime = 0; > [[NSNotificationCenter defaultCenter] postNotificationName:kTabBarBackgroundDoubleClickedNotification > object:mTabView]; >+ } > } What happens if you click thrice rapidly in the spot where the last tab's close button is/was? Shouldn't that do a quick close-open? (It doesn't have to be so rapid if the double-click interval is way slow.) Looks like we're going to be penalized because the events will have increasing clickCounts.

Alrighty, try this version. And yes, if you click 4 or more times it doesn't keep cycling correctly, but at that point I don't care (especially since Cocoa event dispatch doesn't really work correctly at that point).

Comment on attachment 293298 [details] [diff] [review] v3 #include <Carbon/Carbon.h> Otherwise, everything else seems pretty sound.

Landed on trunk and MOZILLA_1_8_BRANCH with the header include changed.