Closed Bug 575248 Opened 14 years ago Closed 13 years ago

Double-click on the Tab Toolbar still acts on the window size when tabs are on bottom

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 7
Tracking Flags:
Tracking Status
blocking2.0 --- .x+

People

(Reporter: jmjjeffery, Assigned: Felipe)

References

Details

(Whiteboard: [parity-IE][parity-opera][4b9])

Attachments

(3 files, 5 obsolete files)

new tab / window resizing in the title/tab bars
9.84 KB, image/png
Details
Patch
1.94 KB, patch
jimm
: review+
Details | Diff | Splinter Review
Patch v5
5.67 KB, patch
dao
: review+
Details | Diff | Splinter Review 
With today's nightly double-clicking on the Tab-Toolbar no longer opens a new tab, but instead causes the browser to become un-maximized. 

More fall-out from getting Drawing in Titlebar working.
blocking2.0: --- → ?
We might want to get Alex or another ux person to comment here about how we want mouse events to interact with various areas.
Note that this ONLY happens when you have the menu bar disabled.
I was just playing with this a bit. I think all areas of glass should have the same result, since there's no visible boundary. Maybe we should tie this to a pref too, as I'm sure different people will prefer different things. (myself, I like that it maximizes as I don't use double-click to open tabs.)
I was just comparing Chrome (5.0.375.86 beta) and it behaves like we do at the present.  Double-click on the tab-strip will maximize/unmaximize the browser. 

So perhaps this is the way it works when the 'title-bar' is removed.
Hmm, interesting, so its either one or the other, I think the lack of double clicking to max/min the window would be a more important default as the latter has a number of other common ways to open a tab.
On second thought:

(In reply to comment #5)
> Hmm, interesting, so its either one or the other, I think the lack of double
> clicking to max/min the window would be a more important default as the latter
> has a number of other common ways to open a tab.

Its seems the tab bar issue is more than this bug about double-clicking, as middle-click on tab bar doesn't open a tab either on the tabs toolbar.
Not sure that this is a regression, really - this might just be a consequence of the new design. Middle-click still works as you'd expect, and there's a new tab button, so, I'm not sure I'm broken up about this loss.
blocking2.0: ? → beta2+
Keywords: regression → uiwanted
(In reply to comment #7)
> Not sure that this is a regression, really - this might just be a consequence
> of the new design. Middle-click still works as you'd expect, and there's a new
> tab button, so, I'm not sure I'm broken up about this loss.

I'm not sure if this bug is clear, but is with the App Menu showing and menu bar disabled, with Aero Glass.  The double click and middle click are not working as expected if trying to do to the right of the tabs which works when the Menu bar is enabled.
This occurs with "tabs-on-bottom" too, which is actually really annoying.
(In reply to comment #6)
> On second thought:
> 
> (In reply to comment #5)
> > Hmm, interesting, so its either one or the other, I think the lack of double
> > clicking to max/min the window would be a more important default as the latter
> > has a number of other common ways to open a tab.
> 
> Its seems the tab bar issue is more than this bug about double-clicking, as
> middle-click on tab bar doesn't open a tab either on the tabs toolbar.

I just checked, and Chrome does not open a new tab on mid-click either.  Not saying they are right, but we seem to have the same functionality since the change to drawing in the title bar.
blocking2.0: beta2+ → ?
(In reply to comment #9)
> This occurs with "tabs-on-bottom" too, which is actually really annoying.

Yeah, that's not right!
blocking2.0: ? → final+
With tabs on top, we can't have an invisible line where above the line double clicking maximizes the window, and below the line double clicking creates a new tab.  This will somewhat break users since we are changing the double click behavior in the tab strip, but in the new UI it doesn't make as much sense.  You are visually acting on the window, the glass part, so it is more logical that the result of that action would be maximizing it.  Also, drag actions on the empty glass part of tab strip need to drag the window around.

For tabs on bottom we can keep the previous behavior of double click to create a new tab.
If the background of the tab is covered in css, then the original behavior works.

Felipe, Doesn't bug 555081 have toolbar inclusion for glass events?  It seems we originally had double-click on the titlebar only.
Right now, the tabs-on-bottom case works the same way because the tab strip is also over the glass part. If you have tabs-on-bottom + Bookmarks toolbar (which removes the glass on them) then the behavior goes back as previously.

So, should we treat tabs-on-bottom as the regular tab strip, even if it's over glass? Would it still drag the window, or is it better if it doesn't drag?
Perhaps it still drags the window, but double click creates a new tab?  It looks draggable, but that far down it loses it's natural mapping to meaning "I want this maximized."
(In reply to comment #12)

This is an interesting comment, as changing the traditional windows title bar may change people's expectations of how it acts - i.e. is there still a strict title/window split. However, other (familiar) windows apps that draw in the title bar, such as MS Word 2007, still limit double clicking to maximise behaviour to just the title bar (glass is limited to title bar though). 

Would it not be wise to maintain as much of the expected OS function as possible? For an anecdote, I asked the guys in my lab (mix of tabs on top and bottom users, all comps windows though some are mac users at home) and they still expected/preferred a split between title bar/window even when the glass is continuous above the location bar (i.e. tabs on top).
(In reply to comment #12)
> With tabs on top, we can't have an invisible line where above the line double
> clicking maximizes the window, and below the line double clicking creates a 
> new tab.
Is this a technical or philosophical decision? Can we get a visible 1px line
instead?
> This will somewhat break users since we are changing the double click
> behavior in the tab strip, but in the new UI it doesn't make as much sense. 
> You are visually acting on the window, the glass part, so it is more logical
> that the result of that action would be maximizing it. 
Maximizing the window by double clicking on an empty part of the window is not
a Windows convention. This only happens because the Glass gets enlarged and
overdrawn with other elements. IMHO it's logical to have Maximize/Restore only
work in "real" title bar (as in Windows Classic skin). Also, by clicking on top
of the tab bar, resizing is the desired action, but by double clicking on the
empty space IN the (invisible) tab bar, i want to launch (open) a new tab. I
don't see how this behavior is inconsistent.

> Also, drag actions on the empty glass part of tab strip need to drag the 
> window around.
They do. Is it impossible to have a double click open a new tab because of
this?

Also, IF the whole top glass section should act as one, the right-click context
menu should be the same/none on all glass surface.
>Also, IF the whole top glass section should act as one, the right-click context
>menu should be the same/none on all glass surface.

I agree, we are also in need of a major context menu overhaul, it isn't at all clear what type of menu you are going to get (tab based, customize the toolbar, bookmark based, system menu).
I actually think that opera 10.5 has a pretty good scheme (and uses about the same amount/layout of glass with tabs on top) for dealing with this:

Double click above tabs: Maximise
Double click on tab bar: open new tab
Click and drag anywhere on glass: move window

Right mouse above tabs: usual title bar context menu
Right mouse on tab bar: tabs context menu
(In reply to comment #17)
> (In reply to comment #12)
> > With tabs on top, we can't have an invisible line where above the line double
> > clicking maximizes the window, and below the line double clicking creates a 
> > new tab.
> Is this a technical or philosophical decision? Can we get a visible 1px line
> instead?

The interesting think is the bookmarks & nav bar do show an outline below tabs on top and is there even with tabs on bottom if we use a persona.
> Is this a technical or philosophical decision? Can we get a visible 1px line
> instead?

it's a decision based on what we think the user's expectations are going to be.  While some users are very used to double clicking the tab strip to create a new tab, they might not even believe that they can still do that when the tabstrip is now visually "the window."  And if they didn't know that they could previously do that, then they will very strongly expect that the section of glass has a consistent behavior throughout its surface.

if they both know that they can double click to create a new tab, and they lso still think this is the case when the tab strip is basically gone, they are going to be surprised once when it doesn't work.  However, we believe this group is smaller.
I don't mind click and hold dragging on the glass areas to move the window or right click and get the system menu, but I think for toolbars to consume the titlebar functionality (double and middle click events) over its normal behavior seems like not the right design.
(In reply to comment #22)
> I don't mind click and hold dragging on the glass areas to move the window or
> right click and get the system menu, but I think for toolbars to consume the
> titlebar functionality (double and middle click events) over its normal
> behavior seems like not the right design.

Oh, wait, I think the system menu should follow the titlebar only, the tab strip context menu should show when right click on the tabs toolbar and nav bar shows toolbar customization in its own context menu.
It's on all area's with aero glass. The title bar seems to be spread out and taking over the glass. Probably a flaw in the method used for placing the orange button on the top.

It does not only happen on the tab bar, but between elements on the navigation bar.
Windows Explorer has the exact same issue, only it acts as a feature rather than on bug.
workaround:
add this to userChrome.css

#navigator-toolbox:not([tabsontop="true"]) > #TabsToolbar {
  -moz-binding: url("chrome://global/content/bindings/toolbar.xml#toolbar") !important;
}

you can drop :not([tabsontop="true"]) if you like it work as before also when tabs are on top.
(In reply to comment #26)
> Windows Explorer has the exact same issue, only it acts as a feature rather
> than on bug.

But in our case, we really had separate toolbar functionality before it landed, so comparing it to explorer is not a great comparison, and leaving this as is, is like saying we don't care about the other functionality that used to work and now regressed.
Blocks: 590035
So the technical issue here is that the glass is now part of the window's nonclient area, right?  This definitely seems like unexpected behavior to me, even in tabs on top.
Yes, there's that technical issue (differentiate the tabstrip glass and the titlebar glass would need some hacks due to the way it's built atm), and it's also a UX issue, because this would create an invisible line where the double click behavior would change from the system default behavior.

Note that middle clicking to open a new tab should work (well actually it doesn't right now due to bug 590035, but I've got a patch for that)
Works for me on trunk build Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100827 Minefield/4.0b5pre
(In reply to comment #34)
> Works for me on trunk build Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre)
> Gecko/20100827 Minefield/4.0b5pre

This applies with the app menu, not the menu bar, so this bug is still valid.
Whiteboard: [parity-IE]
This is marked as blocking, so I assume we'll want some change in behavior from how it currently works (or maybe the blocking flag was set to give more thought about this). Either way, assigning it to myself. I'll proceed whenever we have defined the behavior wanted.
Assignee: nobody → felipc
Status: NEW → ASSIGNED
We should do what IE9 does. Let double click open a tab, in addition to the tab bar being a drag target for moving the window.
I think the distinction (Title Bar = maximize; Tab Strip = new tab) should be kept. The question is: how to make a visual distinction in the UI? How about drawing a thin (glassy) line, but only show it on hover?
We don't want any visible border there.
(In reply to comment #39)
> We don't want any visible border there.

Agreed.

Here's how it goes: looks exactly the same and does exactly the same things, except when you double click in the tabbar area, a new tab is made. That's it.

Also, it should be worth noting that the window should still be draggable while holding the tabbar.
(In reply to comment #39)
> We don't want any visible border there.

Won't that *seem* inconsistent to users, especially when they are clicking near the (invisible) demarcation line? "Sometimes, when I click in that glassy area it maximizes, and sometimes it creates a new tab." <head scratch, confused, irritated>

The border would be invisible most of the time. Only when a user *hovers* in the glassy are does a thin and subtle line appear. It might look like ****. It might not be bad at all. Would it be possible to see it in a mock-up?
You seem to assume that the user would always want to double click when moving the mouse over that area. That doesn't seem like a valid assumption, so the visible feedback would add noise when it's not wanted.
I think the user would rarely move into that area (it's away from most day-to-day UI and content), and when they do, it is *usually* to either maximize the window or add a tab. And for the rare cases when they move there for another reason[1], I'm hoping the subtle line that appears on hover would not be bothersome compared to the beneficial use it might provide. To test that, I suggested a mock-up.

[1] The only other common reason I can think of is to reach the Menu; and that is way on the left where the line-on-hover would be even less noticeable because it would be sandwiched between the visually more dominant Tab and Menu (if visible there at all).
(In reply to comment #43)
> (if visible there at all).

Perhaps the line-on-hover would start after the right edge of the rightmost tab, and end at the "Group Your Tabs" Button (or whatever leftmost button is there).
Making visible lines would be ugly, especially with Personas, but even with the default Aero theme, too, and would not be too useful.
Visible lines could be available as a Stylish style, though.
(In reply to comment #19)
> I actually think that opera 10.5 has a pretty good scheme (and uses about the
> same amount/layout of glass with tabs on top) for dealing with this:
> 
> Double click above tabs: [Maximize]
> Double click on tab bar: open new tab
> Click and drag anywhere on glass: move window
> 
> Right mouse above tabs: usual title bar context menu
> Right mouse on tab bar: tabs context menu

Firefox should use this scheme as well.
>Let double click open a tab, in addition to the tab
>bar being a drag target for moving the window.

I generally don't think that supporting double clicking is that important given that we have a new tab button, but this would be an acceptable compromise on Windows 7.  On XP, I think we may need to keep double clicking as a way for the user to act on the Window, since we aren't planning on a visible border between the title bar and tab strip.
As far as I can tell, the blocking status only applies to fixing this for tabs on bottom, mentioned in comment #11
(In reply to comment #47)
> >Let double click open a tab, in addition to the tab
> >bar being a drag target for moving the window.
> 
> I generally don't think that supporting double clicking is that important given
> that we have a new tab button, but this would be an acceptable compromise on
> Windows 7.  On XP, I think we may need to keep double clicking as a way for the
> user to act on the Window, since we aren't planning on a visible border between
> the title bar and tab strip.

I have Windows 7 and Vista. I never use the new tab button. I always remove it via "customize". To me, it is an annoyance. In the minority or not, I'd be very disappointed if the double click on tab bar to open new tab were removed.
I think some of you are not giving users enough credit. There is a good 5px of padding between the title bar and the tab bar when in 'taps on top' mode. Give yourselves some credit; this UI has nice clean breaks, even without a solid black line. Users can figure out the difference between the two and I think any issue relating to that are over speculation.

Also, the double-click-to-open-new-tab feature has been part of Firefox since before I can remember. Why drop it now? It doesn't clean up the interface (which is clearly the goal of the new UI). It just seems like a case of over-thinking it.

One other note, the new tab button is not a great fallback if this feature is removed. Why? Because it moves. When a new tab is opened, the button moves to the end of the current set of tabs. It never stays in the same place unless the tab bar is full. Now I understand you guys are doing everything in your power to make Firefox faster, but isn't there something to be said for helping users browse faster as well? Because the tab bar is large and stationary, a user can acquire a muscle memory of moving the mouse strait up to the tab bar (with no no regard to horizontal movement) and double clicking. With the new tab button, they have to guess where it is, and the user never acquires that muscle memory; they never get faster on their own.
(In reply to comment #51)
> this UI has nice clean breaks, even without a solid black line.

FWIW: IMO the line should be glassy (not black) - like a groove etched in with a glass cutter. And it would only appear when the mouse is in that area. Win-win.
@Peter do you actually have an idea how weird a line would look like? (doesnt matter if its glassy or not)
Do what IE9 and Opera does, see comment #19
I have no idea whether a glassy line (that only appears on mouse-over!) would look "weird". That is why I requested a mockup in comment #41. I think the cost (temporary weirdness) would be outweighed by the benefit (visual differentiation of the two regions).

I agree with the suggestions in comment #19. But they are independent of the need for some *visual clue* as to where and why mouse-clicks behave differently in the currently seemingly same region.
Attached patch Patch — — Splinter Review 
This patch makes the new tab open on double click both for tabs on top and tabs on bottom, as has been suggested in a few comments here. It seems that this works well as the tab bar is still draggable for Aero Snap, but it's easy to change this to tabs-on-bottom only if wanted.

Jim, talking with gavin/smaug the other day on #developers this was the approach suggested to raise a double click event from widget code. The NS_MOUSE_DOUBLECLICK will set clickCount = 2 and dispatch a mousedown, and the following NS_MOUSE_UP inherits the clickCount and then the EventStateManager generates a doubleclick.
Attachment #487377 - Flags: review?(jmathies)
(In reply to comment #55)
> Created attachment 487377 [details] [diff] [review]
> Patch
> 
> This patch makes the new tab open on double click both for tabs on top and tabs
> on bottom, as has been suggested in a few comments here. It seems that this
> works well as the tab bar is still draggable for Aero Snap, but it's easy to
> change this to tabs-on-bottom only if wanted.
> 
> Jim, talking with gavin/smaug the other day on #developers this was the
> approach suggested to raise a double click event from widget code. The
> NS_MOUSE_DOUBLECLICK will set clickCount = 2 and dispatch a mousedown, and the
> following NS_MOUSE_UP inherits the clickCount and then the EventStateManager
> generates a doubleclick.

Seems to work, although I don't understand why the event state manager needs NS_MOUSE_BUTTON_UP. Shouldn't the double click event be sufficient to trigger a double click event?
I tried that at first, but turns out it works differently. The NS_MOUSE_DOUBLECLICK message is just converted to a mousedown event with clickcount = 2 on DispatchMouseEvent. But the ESM only triggers the double click event after receiving the subsequent mouseup event too.  There's no way to tell the ESM directly to dispatch a {double}click event.
Attachment #487377 - Flags: review?(jmathies) → review+
>it's easy to change this to tabs-on-bottom only if wanted.

please make that change.  For tabs on top, having a single visual surface that has two different double click behaviors is overly complicated.  (To address the  questions: We are not interested in drawing a line since that would significantly increase the overall visual complexity of the UI.)
Both IE9 and Opera do it and work very intuitive in my view (Chrome doesn't though).

This is mainly an empirical question though, which is hard to answer with arguments; does it cause confusion or increase efficiency for users? Considering that double clicking is a command used by technically more advanced users and that opening new tabs generally happens a lot more than resizing the window, I think the more complicated way is preferable. Moreover, although you can't visually distinguish the two areas, they are logically distinct, since one is the title bar, the other part of the program itself. But that's my own view. Ideally this should be answered with statistics.
Attached patch patch - WIP browser part (obsolete) — — Splinter Review 
Dao, I think we'll need some theme-specific behavior here. For the Windows themes that have an integrated titlebar+tabbar look (like the mockups), we'll want the tabsontop case to maximize the window on dblclick, while the themes where the tabbar look is discrete we'll want to open a new tab on both tabs positions.

Do you have any suggestions on how to approach that on this code?
Attachment #489333 - Flags: feedback?(dao)
Whiteboard: [parity-IE] → [parity-IE][needs feedback dao]
Whiteboard: [parity-IE][needs feedback dao] → [parity-IE][parity-opera][needs feedback dao]
Discussed in triage - intended functionality with tabs on top, broken for tabs on bottom but that's not enough to block the release on it - candidate for fixing in 4.x
blocking2.0: final+ → .x
Updating summary to make it more clear that this behavior is only wanted for when tabs are on bottom.
Summary: Double-click on the Tab Toolbar does not open tab - un-maximizes instead → Double-click on the Tab Toolbar still acts on the window size when tabs are on bottom
Why? Even IE 9 doesn't do this when tabs are on top.
So let me get this straight your proposing we go from these 5:
--------------------------------------------------------------

1a) Menu Bar + Glass + Tabs on Top or Tabs on Bottom, double click opens a new tab.

2a) Menu Bar + Bookmarks Toolbar Open + Tabs on Bottom, double click opens a new tab.

3a) -->Fx Menu + Glass + Tabs on Top, double click acts on the window.

4a) -->Fx Menu + Glass + Tabs on Bottom, double click acts on the window.

5a) Fx Menu + Bookmarks Toolbar Open + Tabs on Bottom, double click opens a new tab.


To these 5:
------------------------------------------------------------------------

1b) Menu Bar + Glass + Tabs on Top or Tabs on Bottom, double click opens a new tab.

2b) Menu Bar + Bookmarks Toolbar + Tabs on Bottom, double click opens a new tab.

3b) -->Fx Menu + Glass + Tabs on Top, double click acts on the window.

4b) -->Fx Menu + Glass + Tabs on Bottom, double click opens a new tab.

5b) Fx Menu + Bookmarks Toolbar Open + Tabs on Bottom, double click opens a new tab.

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

And only proposing changing going from 4a to 4b while keeping 3a = 3b ...
The status of the menu bar, and glass are unlreated.  Just:

Tabs on top (single surface): double click acts on window
Tabs on bottom (isolated and visually distinct tab strip): double click creates a tab
(In reply to comment #66)
> The status of the menu bar, and glass are unlreated.  Just:
> Tabs on top (single surface): double click acts on window

Will there be a way to revert to the old behavior through about:config?
This new behavior is insanely annoying for people that are used to double click on the tab bar to open a new tab.
Whiteboard: [parity-IE][parity-opera][needs feedback dao] → [parity-IE][parity-opera][needs feedback dao][4b9]
I have disabled the Litmus test for the time being:
https://litmus.mozilla.org/show_test.cgi?id=10542
Flags: in-litmus?
The [parity-IE][parity-opera] labels should be removed from the whiteboard since this bug has morphed. I still fail to see how this new tab bar behavior is better than what Opera and IE does in any aspect except for alienating Firefox users.
>uiwanted

Details in comment #66, but add back if there are any questions about the wanted ui.
Keywords: uiwanted
Seems odd to me. I have installed FF 4b12 at work and at home (different machines).
I tried the method in comment#66: works at work, but doesnt work at home install..
Installed FF 4b12 to try it a few days ago. I uninstalled a few hours later because of this issue. Some of us really got used to using double click on the tab bar to open a new tab. Following a moving new tab button is *SO* less productive. If you want to open 3 new tabs i.e. a simple 3 double click procedure becomes a chasing the carrot procedure - are we donkeys?

The Opera scheme, as others proposed, seems to be the best. I fully agree with the comments of Denis and Dominic and especially with Daniel's comment (#51).

Anyway, this is just one more vote to keep the old behavior either the tab bar is on the top or the bottom of the window. It seems -though- that votes is not what this matter needs, since the majority of the people who commented in here want the old behavior but, as it seems, the professional opinion (Alex's) has more merit.

So maybe we should just hope there's an option for that or someone creates an addon which fixes it.
Created an account just to comment on this bug which has blown my mind. Please resolve this as soon as possible as to abandon a useability feature a lot of users find integral to their browser experience is truly dreadful. I shall tell you what my expectations are when I double click the tab bar after using and developing with Firefox for eight years. I expect it to open a tab.
So there are two groups of users: Those who want to double click to maximize the window, and those who want to double click to create a new tab.

What do we do when we run into such conflicts of interest?

Bad reaction: Speculate about what group is larger and then declare one of the two option to be the only possible/reasonable/doable way.

Good reaction: Add a goddamn setting to the options dialog and let each user choose for himself.
^this or tell people to use middle click, which is already working ;)
The middle click button is generally non-existing on laptop trackpads ;) Having tabs on top and the menu bar on, double-clicking to get a new tab still works in Fx4 final though. The Chrome behavior is a standard window behavior on Windows at least, but there is no precedent for that behavior in tabbed applications as far as I can see.
(In reply to comment #76)
> So there are two groups of users: Those who want to double click to maximize
> the window, and those who want to double click to create a new tab.
> 
> What do we do when we run into such conflicts of interest?
This bug is for double-clicking when tabs are below the toolbars. Maximizing on double-click of tab bar on bottom makes no logical sense.
Since I use the middle-click for opening the last closed tab, I'm in for opening a new tab on double clicking. I've thought about having a "big" semi-transparent new tab button, the size of a tab, and that only works on double click, but that would really be awful. Just let us make that choice, even if it's thru changing about:config settings. I, for example, would rather have a maximize function when the window is restored (not maximized) and an open new tab function when it's maximized.
Someone said about having 5px paddings, I don't have 5 pixel paddings about the tabs, I may have 2 or 3, but clicking at the top most position still selects the tab below it.
I also created an account just to vote on this bug.
I found that if you hold the right mouse button down while double-clicking the left mouse button, you can get a new tab to appear. It does have a side effect of also showing the context menu, so even this workaround is still very annoying. Please fix!
This seems to be fixed in the trunk nightly builds[1]. I have tabs on bottom, and when I double-click on the tab bar, I get a new tab (and the window does not maximize). NB: I have my Bookmarks Toolbar visible.

[1] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110324 Firefox/4.2a1pre ID:20110324144234
wfm on 4.0
You need the Fx menu, no bookmarks toolbar, no lwtheme, default theme to see this bug. See comment 65, 4a.
When i check menu bar and i double click on empty tab bar, it can open new tab. But When menu bar in check , there is huge lag when loading bookmark toolbar and when open firefox.
(In reply to comment #27)
> workaround:
> add this to userChrome.css
> 
> #navigator-toolbox:not([tabsontop="true"]) > #TabsToolbar {
>   -moz-binding: url("chrome://global/content/bindings/toolbar.xml#toolbar")
> !important;
> }
> 
> you can drop :not([tabsontop="true"]) if you like it work as before also when
> tabs are on top.

but it does help only when Fx window not in the full-screen mode.
How to make doubleclick on tabbar to open a new tab when firefox is in fullscreen mode?
btw, mark this bug fixed, the issue is gone (I'm on Win 7 with latest Fx nightly).
(In reply to comment #88)
> btw, mark this bug fixed, the issue is gone (I'm on Win 7 with latest Fx
> nightly).

No. Please do not, please read comments before commenting its fixed.
Hmm...  maybe i found the root of this problem is --> Personas 1.6 ( Addon) after i disable skin in personas, i can open new tab using double click on empty tabs bar.
Even Personas 1.6.2 ( 2 Apr 2011 ) didn't fix this problem.
Update again, 

if window 7 user active aero theme + personas , when double click on empty tabs bar it's only max/mini mize.

if window 7 user not active aero theme + persona, it can open new tab using double click on empty tabs bar.
update 2, i forgot to add.

if window 7 user not active aero theme + No personas, when double click on empty tabsbar it's only max/mini mize.

LOL.

so, 
if u want to use persona, don't use window 7 aero theme.
if U want to use aero theme, don't use personas.
Comment on attachment 489333 [details] [diff] [review]
patch - WIP browser part

We won't need theme-specific code anymore, so I can change this f? to r?
Attachment #489333 - Flags: feedback?(dao) → review?(dao)
Comment on attachment 489333 [details] [diff] [review]
patch - WIP browser part

please update the tabbrowser part, it doesn't apply anymore
Attachment #489333 - Flags: review?(dao)
Attached patch patch (obsolete) — — Splinter Review 
updated, and included widget part together
Attachment #489333 - Attachment is obsolete: true
Attachment #531858 - Flags: review?(dao)
Comment on attachment 531858 [details] [diff] [review]
patch

This looks like it breaks double-click behavior for tabs on top on XP (or classic on Win 7, as another example).
Attachment #531858 - Flags: review?(dao) → review-
Another note, if I remember correctly the function of middle clicking the empty space on tab bar which is below the toolbars in FF3 was to open the previously closed tab. I really did appreciate that feature as well as double clicking. But honestly, I wouldnt mind this being fixed in an add-on or a about:config setting.

I agree with comment 24, as when the menu bar is shown and the orange button disappears, the double click action is what users are used to, as well as the title of the page you are currently viewing being displayed at the top which I always found rather nice.

But this issue is more so relevant to power users and the such, IMHO, as the average user I am sure would either decide to get used to the new way or just ask one of us to fix it for them...
Attached patch Patch v2 (obsolete) — — Splinter Review 
> This looks like it breaks double-click behavior for tabs on top on XP (or
> classic on Win 7, as another example).

Ok, we also need to take into account the toolbar-drag binding for the theme.
Dao, I also added the check for tabs in titlebar because even if in the non-maximized window the styles are not merged (e.g. classic or XP), they do when the tabs go into the titlebar. Do you think this is the correct behavior?
Attachment #531858 - Attachment is obsolete: true
Attachment #532864 - Flags: review?(dao)
Comment on attachment 532864 [details] [diff] [review]
Patch v2

I find the way the logic is organized slightly messy / confusing... Basically this patch is fine, but I'd like to see an updated version.

>+        let shouldOpenTab = event.button == 0 &&
>+                            event.originalTarget.localName == "box";
>+#ifndef XP_MACOSX
>+        if (this.parentNode._dragBindingAlive ||
>+            window.document.documentElement.getAttribute("tabsintitlebar")) {

There's no need to enter this branch when shouldOpenTab is false.

nit: remove "window."

You should compare getAttribute("tabsintitlebar") to "true". Alternatively, add a getter to the TabsInTitlebar object like we have for TabsOnTop (see below).

>+          // When the tabbar has an unified appearance with the titlebar
>+          // and menubar, a double-click in it should have the same behavior
>+          // as double-clicking the titlebar
>+          shouldOpenTab = shouldOpenTab &&
>+                          (this.getAttribute("tabsontop") != "true");

use TabsOnTop.enabled
Attachment #532864 - Flags: review?(dao) → review-
Attached patch Patch v3 (obsolete) — — Splinter Review 
I moved the conditions around and reorganized things a bit to make the logic clearer.
Attachment #532864 - Attachment is obsolete: true
Attachment #536514 - Flags: review?(dao)
Comment on attachment 536514 [details] [diff] [review]
Patch v3

>--- a/browser/base/content/browser.js
>+++ b/browser/base/content/browser.js
>@@ -5079,16 +5079,20 @@ var TabsInTitlebar = {

>+  get enabled() {
>+    return document.documentElement.getAttribute("tabsintitlebar") == "true";
>+  },

There are two places in the TabsInTitlebar code where you can use this new getter.

>+        // When the tabbar has an unified appearance with the titlebar
>+        // and menubar, a double-click in it should have the same behavior
>+        // as double-clicking the titlebar
>+        unifiedTitlebarBehavior = (this.parentNode._dragBindingAlive ||
>+                                   TabsInTitlebar.enabled) &&
>+                                  TabsOnTop.enabled;

I think this probably makes slightly more sense:

TabsInTitlebar.enabled ||
TabsOnTop.enabled && this.parentNode._dragBindingAlive;
Attached patch Patch v4 (obsolete) — — Splinter Review 

        Attachment #536514 -
        Attachment is obsolete: true

        Attachment #536697 -
        Flags: review?(dao)

        Attachment #536514 -
        Flags: review?(dao)

        Attachment #536697 -
        Attachment is patch: true

    
    

    
  
Comment on attachment 536697 [details] [diff] [review]
Patch v4

>         this._draghandle.mouseDownCheck = function () {
>           return !this._dragBindingAlive &&
>-                 this.ownerDocument.documentElement
>-                     .getAttribute("tabsintitlebar") == "true";
>+                 this.ownerDocument.defaultView.TabsInTitlebar.enabled;

Just TabsInTitlebar.enabled should work here.

>+#ifndef XP_MACOSX
>+        // When the tabbar has an unified appearance with the titlebar
>+        // and menubar, a double-click in it should have the same behavior
>+        // as double-clicking the titlebar
>+        unifiedTitlebarBehavior = TabsInTitlebar.enabled ||
>+                                  (this.parentNode._dragBindingAlive && TabsOnTop.enabled);
> #endif

I think I'd prefer:

if (TabsInTitlebar.enabled ||
    (this.parentNode._dragBindingAlive && TabsOnTop.enabled))
  return;

>+        let shouldOpenTab = event.button == 0 &&
>+                            event.originalTarget.localName == "box" &&
>+                            !unifiedTitlebarBehavior;

and:

if (event.button != 0 ||
    event.originalTarget.localName == "box")
  return;

    
    

    
  
Err, event.originalTarget.localName != "box"

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v5
        — 
          — Splinter Review
      

    


  
comments addressed

        Attachment #536697 -
        Attachment is obsolete: true

        Attachment #539343 -
        Flags: review?(dao)

        Attachment #536697 -
        Flags: review?(dao)

    
  

        Attachment #539343 -
        Flags: review?(dao) → review+

    
    

    
  
http://hg.mozilla.org/mozilla-central/rev/f5d0530311c0
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [parity-IE][parity-opera][needs feedback dao][4b9] → [parity-IE][parity-opera][4b9]
Target Milestone: --- → Firefox 7

    
    

    
  
Setting resolution to Verified Fixed.
Status: RESOLVED → VERIFIED

    
    

    
  
on window 7 
double click on the Tabs Toolbar does nothing when tabs on top and menu-bar is visible (i.e - tab not in title-bar) - neither new tab or window size is working

is it the right behavior ?

    
    

    
  
With Firefox 57 doubleclicking the tab bar results in resizing the window (MacOS 10.13), this is obviously a regression.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: