Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110313 Firefox/4.0b13pre With the changes introduced on bug 635397 which haven't gotten UI review yet, it is not possible anymore for users to use double click onto the empty area of the tabbar to open a new tab. On all other platforms we still support this feature to open new tabs. Even on OS X where the tabbar also has a unified look. I think that should be relnoted and that we find a better solution post Firefox 4. Setting blocking2.0? to request a fix in a .x release.
Can't reproduce, possibly WFM?
blocking2.0: ? → -
This is on Linux when the menubar is hidden (my guess is that this wasn't what you tested with as it's not in the STR). It is pretty annoying for someone who's gotten used to this behaviour which has existed for many years.
blocking2.0: - → ?
Not a default or supported configuration, doesn't block.
blocking2.0: ? → -
(In reply to comment #0) > On all other platforms we still support this feature to open new tabs. Not true, try this on Windows 7.
Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110315 Firefox/4.0b13pre I can confirm this issue. It is present not only when Menu bar is hidden but also when it is enabled.
(In reply to comment #6) > Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110315 Firefox/4.0b13pre > > I can confirm this issue. It is present not only when Menu bar is hidden but > also when it is enabled. Yes, I was wrong about that in comment 2, sorry. I thought that the unified drag area only applied when the menubar was hidden but that doesn't seem to be true. Mike, what OS could you not reproduce this on in comment 1?
Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 I am also experiencing this issue. If I have the Menu Bar shown, double-clicking the empty tab space opens a new tab. If the Menu Bar is hidden, it instead minimizes/maximizes the application. However, if I hold down the right mouse button while I double-click the left button, it will produce a new tab.
Eric, this bug is for Linux and not for Windows. For your issue please CC to bug 575248.
Hi, I've got same problem here but only since I've updated my distro (mandrva 2010.2 > mageia 1). Could it be related to the update of some system libs (gtk ? 2.20 -> 2.24) Mozilla/5.0 (X11; Linux x86_64; rv:6.0a2) Gecko/20110604 Firefox/6.0a2 (present also with official firefox 4.0.1 and distro one)
I can't reproduce this either, on Linux and Iceweasel 8.
I just updated to mageia2 (2.24.10) and with firefox 13 or aurora, I can't reproduce the problem (I could with firefox 13 on mageia 1). So I guess it isn't a mozilla bug.
for my previous comment : _gtk 2.24.10_
I just noticed this with firefox-49 but only when it's built with Gtk3 (firefox_49.0-5 from debian) The same version built with Gtk2 (firefox_49.0-4, always from debian) works just fine, double-clicking on the unpopulated part of the tabbar does open a new tab. Thanks, Antonio
Verified also with nightly build 52.0a1 (2016-11-10) (64-bit) which also uses Gtk3.
A few more pieces of information: 1) Behavior of the tabbar (new profile): - Left-click: shortly switches cursor to "Move window"-cursor - Left-drag: switches cursor to "Move window"-cursor and moves window until released - Middle-click: opens new tab - Middle-drag: does nothing - Instead of opening a tab Reload All Tabs Bookmark All Tabs... Undo Close Tab ------------------ Navigation Toolbar Menu Bar Additional Toolbar Bookmarks Toolbar TGM: GroupBar Web-Developer Toolbar Add-on Bar ------------------ Customize...
(Please disregard my previous comment, it was posted erroneously)
Detailled description of my experiences with this bug: 0) Scope of observed behavior: - Debian Linux (testing, amd64) - Various Firefox versions > 45.x with GTK3 - Does NOT occur with 45.6.0esr-1, which is GTK2 - Various window managers (fvwm2, twm, ...) 1) Behavior of mouse events on empty parts of the tabbar (new profile): - Left-click: Shortly switches cursor to "Move window"-cursor - Left-doubleclick: Like two single-clicks - Left-drag: Switches cursor to "Move window"-cursor and moves window until released - Middle-click: Opens new tab - Middle-doubleclick: Like two single-clicks - Middle-drag: When drag ends in tabbar, opens new tab, otherwise does nothing - Right-click: Opens the following context menu: Reload All Tabs Bookmark All Tabs... Undo Close Tab ------------------ Menu Bar Bookmarks Toolbar ------------------ Customize... - Right-doubleclick: Opens context menu like single-click, then closes it - Right-drag: Opens context menu like single-click 2) Why this bug is annoying (to me): - It changes a long-standing user interface feature. - It removes a very handy feature. - It sparks user irritation. The new left-click/drag behavior is a pain in the body part we do not speak of, because whenever I want to close a XUL-dialog (like the ublock-origin or umatrix window) by left-clicking in an empty part of the tabbar, I more often than not end up accidentally moving my browser window around my desktop. What the recreational activity we do not speak of? 3) Why middle-click is no alternative for left-doubleclick (for me): - During the intellectual decline of the past decades, people have been contriving all sorts of things that turned out to be scourges for mankind, like spam e-mails, USB plugs, and other atrocities. One of these inventions is the scrollwheel, which itself has proven to be quite useful, until Microsoft chose to add a button to it (patented in 1999). Unfortunately, the scopes of scrollwheel and underlying button intersect (in practice), so it is quite easy to accidentally add one or more scroll events before the desired click event, so users could then end up /closing/ a tab when they wanted to /open/ one, if they had a multi-row tabbar (e.g. via TabMixPlus).
This is a bloody nuisance. I don't care whether this opens a new tab or not, BUT IT MUST NOT RESIZE THE WINDOW. But it does, double-clicking (left mouse button) onto the empty part of the menubar maximizes the window. Clicking on it only once picks up the window (as expected) and maximizes it again on release (as totally undesirable). And yes, it's still present on Firefox 52.0.2, on Linux 64bits.
You need to log in before you can comment on or make changes to this bug.