Last Comment Bug 575248 - Double-click on the Tab Toolbar still acts on the window size when tabs are on bottom
: Double-click on the Tab Toolbar still acts on the window size when tabs are o...
Status: VERIFIED FIXED
[parity-IE][parity-opera][4b9]
:
Product: Firefox
Classification: Client Software
Component: Toolbars and Customization (show other bugs)
: Trunk
: x86 Windows 7
: -- major with 19 votes (vote)
: Firefox 7
Assigned To: :Felipe Gomes (needinfo me!)
:
Mentors:
: 577459 591011 599309 638722 644168 645960 (view as bug list)
Depends on:
Blocks: 555081 590035
  Show dependency treegraph
 
Reported: 2010-06-28 06:14 PDT by Jim Jeffery not reading bug-mail 1/2/11
Modified: 2012-06-09 02:27 PDT (History)
56 users (show)
hskupin: in‑litmus?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.x+


Attachments
new tab / window resizing in the title/tab bars (9.84 KB, image/png)
2010-08-26 12:44 PDT, Dominic
no flags Details
Patch (1.94 KB, patch)
2010-11-01 12:04 PDT, :Felipe Gomes (needinfo me!)
jmathies: review+
Details | Diff | Splinter Review
patch - WIP browser part (1.90 KB, patch)
2010-11-09 15:57 PST, :Felipe Gomes (needinfo me!)
no flags Details | Diff | Splinter Review
patch (2.54 KB, patch)
2011-05-12 00:11 PDT, :Felipe Gomes (needinfo me!)
dao+bmo: review-
Details | Diff | Splinter Review
Patch v2 (3.27 KB, patch)
2011-05-16 21:14 PDT, :Felipe Gomes (needinfo me!)
dao+bmo: review-
Details | Diff | Splinter Review
Patch v3 (3.90 KB, patch)
2011-05-31 20:53 PDT, :Felipe Gomes (needinfo me!)
no flags Details | Diff | Splinter Review
Patch v4 (5.87 KB, patch)
2011-06-01 12:29 PDT, :Felipe Gomes (needinfo me!)
no flags Details | Diff | Splinter Review
Patch v5 (5.67 KB, patch)
2011-06-14 15:33 PDT, :Felipe Gomes (needinfo me!)
dao+bmo: review+
Details | Diff | Splinter Review

Description Jim Jeffery not reading bug-mail 1/2/11 2010-06-28 06:14:43 PDT
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.
Comment 1 Jim Mathies [:jimm] 2010-06-28 06:20:44 PDT
We might want to get Alex or another ux person to comment here about how we want mouse events to interact with various areas.
Comment 2 imradyurrad 2010-06-28 06:22:53 PDT
Note that this ONLY happens when you have the menu bar disabled.
Comment 3 Jim Mathies [:jimm] 2010-06-28 06:29:38 PDT
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.)
Comment 4 Jim Jeffery not reading bug-mail 1/2/11 2010-06-28 08:19:14 PDT
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.
Comment 5 [not reading bugmail] 2010-06-28 09:23:07 PDT
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.
Comment 6 [not reading bugmail] 2010-06-28 10:47:17 PDT
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.
Comment 7 Mike Beltzner [:beltzner, not reading bugmail] 2010-06-28 15:14:43 PDT
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.
Comment 8 [not reading bugmail] 2010-06-28 15:30:37 PDT
(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.
Comment 9 DB Cooper 2010-06-28 16:03:14 PDT
This occurs with "tabs-on-bottom" too, which is actually really annoying.
Comment 10 Jim Jeffery not reading bug-mail 1/2/11 2010-06-28 19:00:13 PDT
(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.
Comment 11 Mike Beltzner [:beltzner, not reading bugmail] 2010-06-28 19:40:24 PDT
(In reply to comment #9)
> This occurs with "tabs-on-bottom" too, which is actually really annoying.

Yeah, that's not right!
Comment 12 Alex Faaborg [:faaborg] (Firefox UX) 2010-06-29 12:21:17 PDT
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.
Comment 13 [not reading bugmail] 2010-06-29 12:30:21 PDT
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.
Comment 14 :Felipe Gomes (needinfo me!) 2010-06-29 14:30:04 PDT
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?
Comment 15 Alex Faaborg [:faaborg] (Firefox UX) 2010-06-29 14:34:34 PDT
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."
Comment 16 DB Cooper 2010-06-29 14:50:03 PDT
(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).
Comment 17 pedroburito 2010-06-29 14:58:35 PDT
(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.
Comment 18 Alex Faaborg [:faaborg] (Firefox UX) 2010-06-29 15:57:06 PDT
>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).
Comment 19 DB Cooper 2010-06-29 16:06:53 PDT
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
Comment 20 [not reading bugmail] 2010-06-29 19:49:57 PDT
(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.
Comment 21 Alex Faaborg [:faaborg] (Firefox UX) 2010-06-29 21:22:09 PDT
> 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.
Comment 22 [not reading bugmail] 2010-06-29 21:46:18 PDT
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.
Comment 23 [not reading bugmail] 2010-06-29 21:48:27 PDT
(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.
Comment 24 Brandon Cheng 2010-07-03 14:31:22 PDT
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.
Comment 25 Noah (oldtimer) [:Noah] 2010-07-03 17:03:50 PDT
*** Bug 576807 has been marked as a duplicate of this bug. ***
Comment 26 Brandon Cheng 2010-07-03 18:13:35 PDT
Windows Explorer has the exact same issue, only it acts as a feature rather than on bug.
Comment 27 tabmix.onemen 2010-07-04 03:23:30 PDT
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.
Comment 28 Jim Mathies [:jimm] 2010-07-08 15:46:22 PDT
*** Bug 577459 has been marked as a duplicate of this bug. ***
Comment 29 [not reading bugmail] 2010-07-08 22:54:05 PDT
(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.
Comment 30 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2010-08-24 10:02:50 PDT
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.
Comment 31 :Felipe Gomes (needinfo me!) 2010-08-24 10:27:14 PDT
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)
Comment 32 Henrik Skupin (:whimboo) 2010-08-26 12:42:16 PDT
*** Bug 591011 has been marked as a duplicate of this bug. ***
Comment 33 Dominic 2010-08-26 12:44:29 PDT
Created attachment 469573 [details]
new tab / window resizing in the title/tab bars
Comment 34 Maniac Vlad Florin (:vladmaniac) 2010-08-27 07:38:10 PDT
Works for me on trunk build Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100827 Minefield/4.0b5pre
Comment 35 [not reading bugmail] 2010-08-27 12:32:40 PDT
(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.
Comment 36 :Felipe Gomes (needinfo me!) 2010-09-20 22:10:10 PDT
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.
Comment 37 Dão Gottwald [:dao] 2010-09-21 00:46:18 PDT
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.
Comment 38 Peter Lairo 2010-09-21 02:52:12 PDT
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?
Comment 39 Dão Gottwald [:dao] 2010-09-21 02:55:02 PDT
We don't want any visible border there.
Comment 40 Dominic 2010-09-21 04:12:18 PDT
(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.
Comment 41 Peter Lairo 2010-09-21 05:31:06 PDT
(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?
Comment 42 Dão Gottwald [:dao] 2010-09-21 05:35:27 PDT
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.
Comment 43 Peter Lairo 2010-09-21 05:58:39 PDT
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).
Comment 44 Peter Lairo 2010-09-21 06:02:53 PDT
(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).
Comment 45 Dominic 2010-09-21 12:19:48 PDT
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.
Comment 46 Dominic 2010-09-21 12:24:23 PDT
(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.
Comment 47 Alex Faaborg [:faaborg] (Firefox UX) 2010-09-21 16:08:38 PDT
>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.
Comment 48 Alex Faaborg [:faaborg] (Firefox UX) 2010-09-21 16:10:40 PDT
As far as I can tell, the blocking status only applies to fixing this for tabs on bottom, mentioned in comment #11
Comment 49 Dave Buco 2010-09-21 18:17:49 PDT
(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.
Comment 50 Henrik Skupin (:whimboo) 2010-09-24 06:24:14 PDT
*** Bug 599309 has been marked as a duplicate of this bug. ***
Comment 51 Daniel Simanek 2010-10-05 03:26:07 PDT
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.
Comment 52 Peter Lairo 2010-10-05 03:35:58 PDT
(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.
Comment 53 Norman Paschke 2010-10-31 15:44:10 PDT
@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
Comment 54 Peter Lairo 2010-11-01 02:49:46 PDT
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.
Comment 55 :Felipe Gomes (needinfo me!) 2010-11-01 12:04:28 PDT
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.
Comment 56 Jim Mathies [:jimm] 2010-11-01 12:37:09 PDT
(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?
Comment 57 :Felipe Gomes (needinfo me!) 2010-11-01 12:47:54 PDT
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.
Comment 58 Alex Faaborg [:faaborg] (Firefox UX) 2010-11-01 17:26:50 PDT
>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.)
Comment 59 pino_sb 2010-11-03 02:27:44 PDT
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.
Comment 60 :Felipe Gomes (needinfo me!) 2010-11-09 15:57:07 PST
Created attachment 489333 [details] [diff] [review]
patch - WIP browser part

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?
Comment 61 Kevin Brosnan 2010-11-14 09:07:28 PST
*** Bug 612137 has been marked as a duplicate of this bug. ***
Comment 62 Johnathan Nightingale [:johnath] 2010-12-15 09:28:25 PST
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
Comment 63 Alex Faaborg [:faaborg] (Firefox UX) 2010-12-15 11:45:28 PST
Updating summary to make it more clear that this behavior is only wanted for when tabs are on bottom.
Comment 64 Brandon Cheng 2010-12-16 14:32:41 PST
Why? Even IE 9 doesn't do this when tabs are on top.
Comment 65 [not reading bugmail] 2010-12-27 19:03:22 PST
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 ...
Comment 66 Alex Faaborg [:faaborg] (Firefox UX) 2010-12-29 15:04:33 PST
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
Comment 67 heraldo 2011-01-08 00:33:42 PST
(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.
Comment 68 Henrik Skupin (:whimboo) 2011-01-25 08:14:32 PST
I have disabled the Litmus test for the time being:
https://litmus.mozilla.org/show_test.cgi?id=10542
Comment 69 heraldo 2011-01-28 03:33:21 PST
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.
Comment 70 Alex Faaborg [:faaborg] (Firefox UX) 2011-02-22 16:30:36 PST
>uiwanted

Details in comment #66, but add back if there are any questions about the wanted ui.
Comment 71 t0per 2011-03-02 00:43:22 PST
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..
Comment 72 Nick Mouratidis 2011-03-08 01:48:53 PST
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.
Comment 73 Henrik Skupin (:whimboo) 2011-03-13 17:12:18 PDT
*** Bug 638722 has been marked as a duplicate of this bug. ***
Comment 74 jonnydetroit 2011-03-23 21:51:10 PDT
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.
Comment 75 Florin Strugariu [:Bebe] 2011-03-24 03:49:27 PDT
*** Bug 644168 has been marked as a duplicate of this bug. ***
Comment 76 Shir Khan 2011-03-24 08:41:28 PDT
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.
Comment 77 Norman Paschke 2011-03-24 09:45:10 PDT
^this or tell people to use middle click, which is already working ;)
Comment 78 heraldo 2011-03-24 10:54:12 PDT
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.
Comment 79 David [:auscompgeek] 2011-03-24 23:54:58 PDT
(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.
Comment 80 Claudio Roberto França Pereira 2011-03-25 10:18:46 PDT
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.
Comment 81 Eric Hamilton 2011-03-25 13:59:28 PDT
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!
Comment 82 Peter Lairo 2011-03-25 14:14:46 PDT
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
Comment 83 eyal gruss (eyaler) 2011-03-25 14:20:40 PDT
wfm on 4.0
Comment 84 [not reading bugmail] 2011-03-25 15:07:22 PDT
You need the Fx menu, no bookmarks toolbar, no lwtheme, default theme to see this bug. See comment 65, 4a.
Comment 85 Henrik Skupin (:whimboo) 2011-03-29 04:55:39 PDT
*** Bug 645960 has been marked as a duplicate of this bug. ***
Comment 86 Ferd 2011-03-29 19:32:44 PDT
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.
Comment 87 *I need to change my userid so it's less racist) 2011-03-31 17:53:30 PDT
(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?
Comment 88 *I need to change my userid so it's less racist) 2011-03-31 17:55:22 PDT
btw, mark this bug fixed, the issue is gone (I'm on Win 7 with latest Fx nightly).
Comment 89 [not reading bugmail] 2011-03-31 18:16:59 PDT
(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.
Comment 90 Ferd 2011-04-02 03:56:49 PDT
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.
Comment 91 Ferd 2011-04-03 06:49:52 PDT
Even Personas 1.6.2 ( 2 Apr 2011 ) didn't fix this problem.
Comment 92 Ferd 2011-04-06 03:21:51 PDT
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.
Comment 93 Ferd 2011-04-06 03:25:36 PDT
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 94 :Felipe Gomes (needinfo me!) 2011-05-11 17:35:20 PDT
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?
Comment 95 Dão Gottwald [:dao] 2011-05-11 23:06:22 PDT
Comment on attachment 489333 [details] [diff] [review]
patch - WIP browser part

please update the tabbrowser part, it doesn't apply anymore
Comment 96 :Felipe Gomes (needinfo me!) 2011-05-12 00:11:48 PDT
Created attachment 531858 [details] [diff] [review]
patch

updated, and included widget part together
Comment 97 Dão Gottwald [:dao] 2011-05-12 02:38:23 PDT
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).
Comment 98 Abhi Saini 2011-05-12 23:17:56 PDT
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...
Comment 99 :Felipe Gomes (needinfo me!) 2011-05-16 21:14:18 PDT
Created attachment 532864 [details] [diff] [review]
Patch v2

> 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?
Comment 100 Dão Gottwald [:dao] 2011-05-25 23:10:37 PDT
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
Comment 101 :Felipe Gomes (needinfo me!) 2011-05-31 20:53:46 PDT
Created attachment 536514 [details] [diff] [review]
Patch v3

I moved the conditions around and reorganized things a bit to make the logic clearer.
Comment 102 Dão Gottwald [:dao] 2011-06-01 00:50:45 PDT
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;
Comment 103 :Felipe Gomes (needinfo me!) 2011-06-01 12:29:39 PDT
Created attachment 536697 [details] [diff] [review]
Patch v4
Comment 104 Dão Gottwald [:dao] 2011-06-03 00:53:05 PDT
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;
Comment 105 Dão Gottwald [:dao] 2011-06-03 00:54:19 PDT
Err, event.originalTarget.localName != "box"
Comment 106 :Felipe Gomes (needinfo me!) 2011-06-14 15:33:29 PDT
Created attachment 539343 [details] [diff] [review]
Patch v5

comments addressed
Comment 107 :Felipe Gomes (needinfo me!) 2011-06-15 15:49:57 PDT
http://hg.mozilla.org/integration/mozilla-inbound/rev/f5d0530311c0
Comment 108 :Felipe Gomes (needinfo me!) 2011-06-16 03:06:04 PDT
http://hg.mozilla.org/mozilla-central/rev/f5d0530311c0
Comment 109 Vlad [QA] 2011-06-22 05:00:16 PDT
Setting resolution to Verified Fixed.
Comment 110 tabmix.onemen 2011-10-17 22:59:35 PDT
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 ?

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