Closed Bug 624129 Opened 14 years ago Closed 13 years ago

A maximized window with tabs in the titlebar isn't easily draggable when there are many open tabs.

Categories

(Firefox :: Theme, defect)

Product:
Firefox
Component:
Theme
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 4.0b12
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: tiago.morbus.sa, Assigned: fryn)

References

Details

(Whiteboard: [hardblocker])

Attachments

(2 files, 6 obsolete files)

Zones that can already be dragged in FF 4 beta 10. (A bit rough :-)
32.03 KB, image/png
Details
hg export of patch v2 [r=dao ui-r=shorlander]
931 bytes, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

As the title says, a maximized window with tabs in the titlebar isn't easily dragable when there are many open tabs. We should create a 1px line at the top edge of the window that will serve as the Fitt's lawed title bar.

Reproducible: Always

Steps to Reproduce:
1. With tabs on top and the window maximized, open many tabs to fill the whole tab strip
2. Try to drag the window out of maximized state by snapping the cursor to the top edge of the screen
3. You can't.
Version: unspecified → Trunk
Depends on: 572160
Adding a 1px border would be again fitts law for selecting the tabs. We should just drag the window, when we start to drag tabs and disable snapping of tabs in maximized mode.
(In reply to comment #1)
> Adding a 1px border would be again fitts law for selecting the tabs. We should
> just drag the window, when we start to drag tabs and disable snapping of tabs
> in maximized mode.

That would increase irritation when one accidentally drags instead of clicks, which happens regularly when using a graphics tablet or tablet pc.
(In reply to comment #1)
> Adding a 1px border would be again fitts law for selecting the tabs. We should
> just drag the window, when we start to drag tabs and disable snapping of tabs
> in maximized mode.

Look at it this way: tabs are 30px high. The titlebar is non-existant.

What do you want to drag by snapping your mouse to the top edge of the screen with Firefox 3.6? The titlebar.

See?
There is a narrow space at with end of the tab strip that can be used to drag the window. On the left between the firefox button and the first tab, on the right between the panorama button and the minimize button.

Narrow admittedly but there.
The whole point of putting tabs on the titlebar because of Fitt's law is to apply Fitt's law, not to remove the titlebar. Moving the window with something that is bellow other content of the window that can't be used to move it is less than intuitive. See Opera and how much better it is than craptastic Chrome.
Wouldn't a 1px space above the tabs in the titlebar be a window resizer, and not a draggable area?
The two purposes for putting tabs in the titlebar while the window is maximized:
- to make it easy to target tabs, since they are selectable by simply moving the cursor to the top edge of the window and clicking
- to reduce toolbar space, since maximizing implies that the user is trying to maximize content area
By adding a 1px space above the tabs, we defeat the first purpose.

To restore to un-maximized mode, simply click the "restore" button next to "mimimize" and "close", or press [Win]+[Arrow Down]. Integrating the "tab detach" behavior better with maximized mode and Aero Snap is something that we'd like to do, but since maximized windows can still be easily restored, this issue doesn't warrant doing that now.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Summary: A maximized window with tabs in the titlebar isn't easily dragable when there are many open tabs. → A maximized window with tabs in the titlebar isn't easily draggable when there are many open tabs.
Thanks for the explanation Frank. I know how to handle this issue, though, no need explaining. I don't tabs in the title bar when maximized.
(In reply to comment #7)
> The two purposes for putting tabs in the titlebar while the window is
> maximized:
> - to make it easy to target tabs, since they are selectable by simply moving
> the cursor to the top edge of the window and clicking
> - to reduce toolbar space, since maximizing implies that the user is trying to
> maximize content area
> By adding a 1px space above the tabs, we defeat the first purpose.
> 
> To restore to un-maximized mode, simply click the "restore" button next to
> "mimimize" and "close", or press [Win]+[Arrow Down]. Integrating the "tab
> detach" behavior better with maximized mode and Aero Snap is something that
> we'd like to do, but since maximized windows can still be easily restored, this
> issue doesn't warrant doing that now.

Except there's more than that much room between the tabs and the location bar and between the location bar and the browser area. Tabs could also be made shorter to get even less space in the toolbars. Could also automatically go into full screen mode when maximized to get even MORE space. So obviously there are reasons to take up these pixels, and have some padding. 1px makes hardly a difference on most screens, and on netbook screens 1px is really pointless as well, full screen mode is the only way to get more content showing.

Maximizing can also imply other things. I use maximize so that I don't accidentally click to another app. Also when I'm only looking at the browser it's distracting to see other applications. It's much simpler to just hit maximize than it is to try and stretch the window to the size of the screen.

1px is really neither here nor there in terms of the viewable content of a page, I'd like to see some screenshots where it does make a significant difference.  I think the real point is that adding 1px wouldn't change the behavior because clicks above the tab will still select the tab no matter how much padding is there.
(In reply to comment #4)
> There is a narrow space at with end of the tab strip that can be used to drag
> the window. On the left between the firefox button and the first tab, on the
> right between the panorama button and the minimize button.
> 
> Narrow admittedly but there.

This is not a valid alternative. If I wanted to aim at that narrow space I'd rather hit the restore button.

Users never had any issues with selecting tabs in previous versions of Firefox when tabs were on the bottom. This whole Fitt's law compliance fix is just a solution looking for a problem to solve. Meanwhile, we're breaking one of the touted window management features of Windows 7.

One of the reasons why I don't like to use Google Chrome is because of its interface design choices, and sadly Firefox is looking more like Chrome everyday.

I know there's a browser.tabs.drawInTitlebar setting, but at least make this a visible preference.
Also the Minefield button now takes up some of the tab bar space, shrinking the size of all the tabs. So sure we have Fitt's law, but now we have a smaller target area on which to aim when selecting a tab. The effect is worsened on smaller screen spaces.
Reopening, since we're going to fix this by ensuring that there is always some glassed space to the right of the tab strip.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Assignee: nobody → fryn
Status: REOPENED → ASSIGNED
(In reply to comment #13)
> Reopening, since we're going to fix this by ensuring that there is always some
> glassed space to the right of the tab strip.

I think this is the worst of all possible solutions. A /small/ glass space would be in no way easier to hit than the restore button, it will probably look weird, and it will decrease the area for the tabs even further.
(In reply to comment #13)
> Reopening, since we're going to fix this by ensuring that there is always some
> glassed space to the right of the tab strip.

Personally I'd also add the same amount of space after the appmenu button, so that there are 2 draggable spaces at both ends and the toolbar does not look unbalanced (simmetry is one of the basics of beauty).

I'm not sure reducing space for tabs in lots-of-tabs case is such a big deal, the more tabs the smaller they are, this always happened, and panorama is here to solve these kind of problems with lots of tabs. I agree that an empty space is not an easier target than the restore button, but that depends on user's preferences (many users prefer d&d gestures), plus I can drag the maximized windows to a screen edge to get a split-screen, something no button can do.
(In reply to comment #12)
> Also the Minefield button now takes up some of the tab bar space, shrinking the
> size of all the tabs. So sure we have Fitt's law, but now we have a smaller
> target area on which to aim when selecting a tab. The effect is worsened on
> smaller screen spaces.

Yeah, tabs in the titlebar is pretty dull because of stuff like that, but who am I to tell other people what to use? Just the same though, who is anyone to tell me what to use? I set it to not-tabs-in-the-titlebar-on-maximize, so it's ok, but it won't be so easy for other people. Specially considering how BAD!!! it works on Chrome and on Minefield ATM. Seriously, check Opera out. It may be only marginally better a browser than Chrome, but in that aspect in particular, it's miles ahead.

Well, pretty much any browser is miles ahead of Chrome in terms of user interface TBH.

Also, thanks Frank for addressing the problem, at least in some way. I still think it's not as good a solution as the one I proposed, but it's up to "you", no "us".

Basically.

If I may say so, though, and I know this is not a discussion forum, but shouldn't Shorlander say something about this? The original mockups don't consider maximized state, so it already looks horrible when it's maximized (IMHO), these changes seem to be a bit too important... I mean, I don't want to offend anyone, I don't know who's in charge of stuff. Sorry about that.
(In reply to comment #13)
> Reopening, since we're going to fix this by ensuring that there is always some
> glassed space to the right of the tab strip.

I agree with Jonathan. The tab space is already small enough thanks to the Minefield button, the Panorama button, the tabs drop down button (whatever you call the arrow that shows all the tabs), and the caption buttons. Also when tabs start scrolling, you have the two additional arrow buttons. All that combined means we have a few inches of space taken up that could have been used for tabs. Sometimes users maximize their windows so they can see their tabs clearly. Adding these draggable spaces is counter-intuitive in this case.

This is also very detrimental to netbook users, because the extra space that's taken up in the tab bar literally will translate to anywhere from 1 to 3 tabs worth of space. So let's take a look at the overall benefits for netbook users, since clearly tabs-in-titlebar is meant to help users with small screens. With tabs-in-titlebar, they gain one extra line of text. On the other hand, they now have to click on way smaller tab buttons and possibly even scroll the tab bar because two or 3 of their tabs have become absolutely inaccessible. How is this a net win for netbook users?

Marco, you might say that we can use Panorama to reduce the amount of tabs in the tab bar, but that is not the point of Panorama. The point of Panorama is to provide a logical grouping tool for tabs. What if I have a group labeled "Christmas shopping" and I browse a lot of stores to compare prices, hence lots of tabs. I am not going to create groups like "Christmas shopping #1" and "Christmas shopping #2" simply to get more tab space. The problem of reduced tab space is still going to be there.

Does nobody else see the amount of additional new problems that arise with tabs-in-titlebar? This reduction of tab space is just one of a myriad of problems.

Disadvantages:
* Breaks platform UI guidelines. No other application besides Google Chrome does this. Tabs-in-titlebar is very Chrome-reactionary, but a lot of users hate the Chrome UI and have not switched because of it. Making Fx4 UI like Chrome would only hasten their switch.

* Breaks platform UI functionality. We have to create pretty bad workarounds to make Aero drag work again. Even with these workarounds, you'll have a lot of people tearing off tabs when they really meant to drag their window.

* Reduced tab space due to existing titlebar items. Use of panorama will not solve this issue.

Advantages:
* Save one line of text.

* Fitt's law. This is pretty moot though, since its a solution looking for a problem that never existed. We can hit our tabs just fine, as we've comfortably demonstrated for most of Firefox's lifetime. Also this law will not apply in windowed mode or with tabs on bottom. If Fitt's law was really necessary, you would start seeing people physically unable to browse the web whenever their browser was in these states. I mean seriously are we really to expect users to click on web links if we can't even assume that users can hit tabs without aid?
(In reply to comment #17)
> Marco, you might say that we can use Panorama to reduce the amount of tabs in
> the tab bar, but that is not the point of Panorama.

I never said (or intended to say) that, I said that with Panorama you can easily identify tabs, much more easily that what an additional letter in the tab title would do for you.
(In reply to comment #18)
> (In reply to comment #17)
> > Marco, you might say that we can use Panorama to reduce the amount of tabs in
> > the tab bar, but that is not the point of Panorama.
> 
> I never said (or intended to say) that, I said that with Panorama you can
> easily identify tabs, much more easily that what an additional letter in the
> tab title would do for you.

Okay I misunderstood you a bit. But on netbooks, it would be much more than a letter.
Tabs only shrink so far unless you set an about:config pref. I tend to identify my tabs by the favicon so one more or less letter isn't the point IMO, it's that people are using more and more tabs and fewer and fewer tabs are showing at once.

I think the real solution to all of these bugs is to have a "tabs in titlebar" preference visible, for many reasons:

- For people who want to preserve the OS behavior
- For people who want to see more tabs at once
- For people who want to see their persona

I suppose there is another bug for adding the pref to UI?
(In reply to comment #20)
> I suppose there is another bug for adding the pref to UI?

Yes, there is. Bug 624262.
As written in #626254, as of now the current behaviour works quite contrary to the common expectations a Windows user usually has when working with maximized windowed applications.

I don't really get Fitts's law, but as I see it, the behavious is also contrary to the actual visible appearance of the tabs in the title bar. While Chrome's tabs use the full height of the "title bar", there *is* a visible margin in Firefox where the actual tab buttons end and the title bar in the background shines through. As such a user not even expects normal behaviour also by the visual appearance.

So I suggest you actually change the behaviour so it matches the Windows UI rules and also the visual appearance and give the top 2-3 pixels a normal title bar behaviour that allows focussing and restoring the window size *without* selecting a tab or something like that.

It's easy enough to hit the tab buttons even without having the top pixels do it. Increasing the margin will probably make that even more clear to users. The argument that there is a different option (like the restore/maximize button on the right) is rubbish, because there are always alternative solutions for common UI operations. That however does not justify getting rid of accepted and standard behaviour a user normally expects from any application.
(In reply to comment #17)
> Does nobody else see the amount of additional new problems that arise with
> tabs-in-titlebar?
I do, and I've talked about them long before it was set in stone(ish) that they'd go there.

> Disadvantages:
> * Breaks platform UI guidelines. No other application besides Google Chrome
> does this. Tabs-in-titlebar is very Chrome-reactionary, but a lot of users hate
> the Chrome UI and have not switched because of it. Making Fx4 UI like Chrome
> would only hasten their switch.
Your points are valid, and I fully agree with them, but I must say that there are other applications that use up the title bar for their own ends. There's one thing in common with all of them: they break platform UI guidelines. I said this loads of times, but tabs in the title bar FORCES the user to manually stretch the window to the edges of the screen rather than simply maximizing the window, which is moronic and stupid.

> * Breaks platform UI functionality. We have to create pretty bad workarounds to
> make Aero drag work again. Even with these workarounds, you'll have a lot of
> people tearing off tabs when they really meant to drag their window.
That, and all the applications that add buttons to ALL windows, like utilities to add a button near the caption buttons to make the window always visible, or transform into titlebar only window, or minimize to tray. Firefox 4 doesn't support those, because it breaks platform UI functionality.

> Advantages:
I always thought the only advantage of tabs in titlebar is to please the geeks who write browser reviews that other geeks read and influence those geeks' opinions and browser choices, who will then influence their family and friends' browser choices too.
> > Advantages:
> I always thought the only advantage of tabs in titlebar is to please the geeks
> who write browser reviews that other geeks read and influence those geeks'
> opinions and browser choices, who will then influence their family and friends'
> browser choices too.

I don't mind it being there, but at least make a UI option that lets us choose. I feel like its not that hard or intrusive to put another checkmark right after "Tabs on Top", but the bug for that is dangerously close to WONTFIX.
The people who are saying "oh but we had no problem selecting tabs before" are missing the point. Of course we had no problem selecting tabs before, but with tabs in the titlebar it becomes faster.

Introducing a 1px margin is IMHO worse than just not putting the tabs in the titlebar, because the screen edge is like a magnet. For me it actually makes selecting tabs harder than it was when they weren't in the titlebar. And it's like snatching defeat from the jaws of victory.

With that in mind, IMHO the best solution is a preference option, or alternatively, the people who don't like tabs in titlebar can already disable tabs on top.
(In reply to comment #31)

> 
> With that in mind, IMHO the best solution is a preference option, or
> alternatively, the people who don't like tabs in titlebar can already disable
> tabs on top.

That might be the best argument for adding the UI pref. Disabling tabs on top to get around this is overkill.
Nominating for fryn's spacer approach so that we don't break users trying to do an areo snap drag down.  Aero snap is so useful that you end up trying to do it on platforms that don't have it (I've caught myself doing it on OS X).
blocking2.0: --- → ?
I am begging you not to do the spacer approach. It is a significant crippling of aero snap and shrinks available tab bar space. I agree with Nikola on the pref option. Something right under "Tabs on Top" in the customize menu would suffice.
The spacer approach isn't very good, but it is really easy.

Here's a much better solution for when we have more time (unless fryn can get this done in the same amount of time):

we introduce a few pixels of space above the tabs that have a glass background (like 3 or 4 pixels).  Drag operations on this area, and on the screen edge act on window, and are aero snap.  Downclick operations in this area will still select the tab below.  If you mouse down a few pixels onto the tab itself, the drag operation acts on the tab for tab tear off.

With this set up, aero snap is actually the easiest drag operation, because you start with an infinite target space (screen edge).  Also, we don't confuse what surfaces act on what.

The exception to the efficiency of this approach is the possibility of users slowly targeting tabs because they *believe* that they can not select the tab by hitting the screen edge, even though they can, which I've previously been (and still am) worried about.
(In reply to comment #35)
> Here's a much better solution for when we have more time (unless fryn can get
> this done in the same amount of time).

I'm not sure how to do this at all or if it's even possible. You'll have to talk to Rob Strong or Jim Mathies to see if you can redirect events that we already captured back to the OS to handle (or whatever is necessary to have the OS handle the drag but not the mousedown).

I'm not particularly happy with the spacer either, but it is an acceptable fix for now.
(In reply to comment #35)
> Here's a much better solution for when we have more time (unless fryn can get
> this done in the same amount of time):
> 
> we introduce a few pixels of space above the tabs that have a glass background
> (like 3 or 4 pixels).  Drag operations on this area, and on the screen edge act
> on window, and are aero snap.  Downclick operations in this area will still
> select the tab below.  If you mouse down a few pixels onto the tab itself, the
> drag operation acts on the tab for tab tear off.
> 
> With this set up, aero snap is actually the easiest drag operation, because you
> start with an infinite target space (screen edge).  Also, we don't confuse what
> surfaces act on what.
> 
> The exception to the efficiency of this approach is the possibility of users
> slowly targeting tabs because they *believe* that they can not select the tab
> by hitting the screen edge, even though they can, which I've previously been
> (and still am) worried about.

Another problem with that approach is that a user might try select a tab using Fitt's law and then end up dragging the window down. We also have the problem where a window drag might switch tabs.

A visible pref is still the EASIEST option right now, considering how we already have browser.tabs.drawInTitlebar. In addition, only Windows 7 has Aero drag. We'll have to write special cases for this platform to add the border above the tabs. That's more code we have to write and maintain. With the pref option, we have to do none of this. Putting it into the customize menu has a very minimal impact on "UI clutter" anyways.
Please do not forget that Aero Drag is not the only operation that is done via the title bar. What is much more important to me personally is being able to focus the Firefox window by single clicking the title bar (i.e. clicking at the very top of the window). Right now the click event is handled by the tab, which is then causing the tab to change. The other function is double clicking to restore the window's original size.

The title bar is not about Aero only, and in fact the current Firefox/Minefield titlebar has real margin above the tabs which, by simple looking, does not belong to the tabs itself and as such should *not* work in the same way as the tab buttons some pixels below. Just make that exact area non-reactive for the tab management and give it normal title bar behaviour and you save all common Windows UI features with a simple fix. And you don't even need to introduce additional margin - although additional margin would help to separate it more, and it, by no means, reduces the available size, because you can't tell me that 2-3px less content area are a real harm.
(In reply to comment #38)
> in fact the current Firefox/Minefield
> titlebar has real margin above the tabs which, by simple looking, does not
> belong to the tabs itself

The margin is only visual and not real in the implementation sense. Look at the window close button. There is a visual margin between it and the right edge of the screen when the window is maximized, but clicking at the top right edge of the screen still closes the window.
Johnath, this needs to be triaged - hardblocking/softblocking and 2.0 (+/-).
(In reply to comment #40)
> Johnath, this needs to be triaged - hardblocking/softblocking and 2.0 (+/-).

All noms do. :) I'm a week behind, but they're absolutely on my list.
The purpose of this bug seems to have morphed through debate.  Here's a quick summary of the ui we want:

1) Downclick on the screen edge activates the tab below (no matter what, this was the purpose of the change to begin with)

2) We find a way for users to access Aero snap on Windows 7 (either by inserting a space, which is quick and kind of lame, or doing some more advanced work discussed in comment #35)

I'm fine with filing a new bug for the spacer if the discussion here is a bit too meandering to easily triage.
One point I didn't see in the discussion above: Aero Snap provides an extremely handy accelerator for multi-monitor support. These old-skool steps...
 1. Restore window (which is a little button, for you Fitts's law folk :-)
 2. Drag to new monitor
 3. Maximize window 

are replaced with a single gesture: 
 1. Grab the window's titlebar and drag (slam!) it into the top of the monitor where you want it maximized.

It's incredibly fast. 

I understand there are conflicting design constraints. Do you want Fitts's law to apply:
 A) only to tabs (inconsistent, surprising, and dare I say, a bit self-centred), or 
 B) only to Windows 7's window manager (you loose the ability to slam the 
    mouse to the top of a maximized Firefox window to select/drag a tab.)

Would this slight refinement on (comment #35) provide a good compromise?
 1. Add 1px space above the tabs when maximised.
 2. Hovering the mouse over this line does not highlight the tab. Dragging anywhere in this line works like dragging any other maximised window. It does not support dragging tabs from here.
 3. If you *click without dragging* (for some definition) this special line, it selects the tab immediately below. 

Point taken about the possible technical difficulty of point 3 (comment #36). 

There are already fragments of glass that can be dragged, and I agree that the spacer will be a "more intuitive" fragment, so that's a marginal improvement. But it's still fiddly to locate, so IMHO doesn't resolve the key usability conflict.
(In reply to comment #43)
> Point taken about the possible technical difficulty of point 3 (comment #36). 
Hmm, would implementing the idea just using 2px outline of the tab buttons that already look like glass, rather than adding the extra 1px, avoid this issue? Just food for thought. Soz for spam! :-)
blocking2.0: ? → betaN+
Whiteboard: [softblocker]
The whole solution to this problem is very simple. There should be one to two "spaces" right after the last tab, if you were to fill the entire title bar.

You can test this out by right clicking the title bar, click the drop down menu "customize", then look for the icon named "space" now drag two of those AFTER the "open a tab button" on your title bar. Viola, that's exactly how it should be.

That's both the easiest and best solution. Just for comparison sake, if you have Google Chrome, fill the entire top bar with tabs and you will see that there is space between the last tab and the next icon. They did it right, so has Mozilla in the past. Aero Snap is awesome, I hope you fix this Mozilla!
I disagree with the above solution. I also use Firefox maximized and I click on the title bar sometimes to focus it when I've just been in a chat or IRC.

I think this is a lot of work for nothing. People who want the titlebar to show don't *Want* fitt's law to apply. The proposed click/drag different behaviours is going to be very confusing. Much ado to avoid a UI pref.
^^ Majken, this is what I mean. I think pictures speak a thousand words, check this picture:  http://oi53.tinypic.com/2hnluhh.jpg

That space is the perfect size. Not to small and not too big. It gives users an acceptable amount of space to grab the title bar. It doesn't matter where the space should be (before the "group your tabs" button, after that button, etc..) but there should be space there by default. Every program known to mankind has a clickable title bar by default, which makes it work with Aero snap.
(In reply to comment #48)
> ^^ Majken, this is what I mean. I think pictures speak a thousand words, check
> this picture:  http://oi53.tinypic.com/2hnluhh.jpg
> 
> That space is the perfect size. Not to small and not too big. It gives users an
> acceptable amount of space to grab the title bar. It doesn't matter where the
> space should be (before the "group your tabs" button, after that button, etc..)
> but there should be space there by default. Every program known to mankind has
> a clickable title bar by default, which makes it work with Aero snap.

This is almost no better than earlier comments noting there is a small gap between tabs and content next to them. One of the things that makes Aero Snap so great is that you don't have to think about what you're doing. You just throw your mouse up to the top of the screen and drag. Having to search for the space where you are able to click is very time consuming, and runs contrary to almost every other program on the Windows 7 operating system. Consistency is important in software design; that's why they have UI guidelines and whatnot.
Please do something about this padding above the tabs. I realise why it's been done but the browser is now awful to use full screen. 50% of the time I miss the tabs and click on the padding space. Surely tab selection is MORE important than title bar selection?
Clicking on that space is still supposed to select the tab. That's the whole point of this bug, that it does that instead of selecting the title bar.
Attached image never mind (obsolete) — 
I'm running Windows XP on a laptop set to a DPI setting of "Large size (120 DPI)" and the different is a lot worse.  Tabs only take up about 60% the title bar.

I never even realized it was supposed to take up the entire title bar.
Oops posted in wrong bug sorry about that.  Please remove that attachment (I'm unable to do so).
Attachment #509891 - Attachment description: Windows XP - 120 DPI → never mind
Attachment #509891 - Attachment is obsolete: true
A few days ago, I installed an add-on that moved my tabs down 1 px.

After two minutes, I was frustrated beyond belief. I kept dragging the window, clicking when I didn't want to. 

I disabled and removed the add-on for that one, small, pitiful reason. It will be fixed soon, but until then, this little glitch ruined my experience of Firefox.

If even Firefox has that 1px space, it could be frustrating to many other users similarly. 

The reason that IE and FF 3.6 could get away with it was because there was quite a bit of distance between the top edge and the tabs. When there is only 1 px, the distance is barely visible. Thus, when a user does not see that 1 px, their first belief would be [as most of the people I know have reacted this way] that the tabs are completely on top. I suggest that if we really need to maintain Win 7's dragging features, we rather do something like Internet Explorer 9 where there is significant space for the title bar. 

However, I firmly believe that most average users will not attempt to drag a maximized window. That is what the restore button is for. There will always be those who use Windows 7's features extensively, but these will be the same people who will easily be able to go into about:config and change the setting with a few searches/a bit of knowledge. I do not think that the average user--the ones that will never post on this forum--will be worried about dragging a maximized window.
Furthermore, is it possible to gather data [test study, possibly?] regarding how many users we see having problems with dragging the window? I state again that I believe this number will be much larger than that of users who select tabs more often than do drag windows.
(In reply to comment #54)
> A few days ago, I installed an add-on that moved my tabs down 1 px.
> 
> After two minutes, I was frustrated beyond belief. I kept dragging the window,
> clicking when I didn't want to. 
> 
> I disabled and removed the add-on for that one, small, pitiful reason. It will
> be fixed soon, but until then, this little glitch ruined my experience of
> Firefox.
>
> If even Firefox has that 1px space, it could be frustrating to many other users
> similarly. 

There is nothing Mozilla devs can do about addons malfunctioning. This responsibility lies solely in the hands of the extension developer.

> The reason that IE and FF 3.6 could get away with it was because there was
> quite a bit of distance between the top edge and the tabs. When there is only 1
> px, the distance is barely visible. Thus, when a user does not see that 1 px,
> their first belief would be [as most of the people I know have reacted this
> way] that the tabs are completely on top. I suggest that if we really need to
> maintain Win 7's dragging features, we rather do something like Internet
> Explorer 9 where there is significant space for the title bar. 

Ditto, I am all for a visible pref that lets you change tab behavior. See bug 624262

> However, I firmly believe that most average users will not attempt to drag a
> maximized window. That is what the restore button is for. There will always be
> those who use Windows 7's features extensively, but these will be the same
> people who will easily be able to go into about:config and change the setting
> with a few searches/a bit of knowledge. I do not think that the average
> user--the ones that will never post on this forum--will be worried about
> dragging a maximized window.

Every single Windows 7 user I know uses window drag. Every single user I've ever installed Windows 7 for thought it was a brilliant feature when I told them about it. It is a well publicized feature of Windows 7 and one that many have become accustomed to.
What I meant regarding the addon was not that the addon was problematic, but that I experienced the possibility [of 1px] that you propose through an add-on glitching, and was frustrated by it. I am not talking about fixing the malfunctioning, but rather stating that I have tried and disliked this "feature."

As for drag, maybe I just know a different, less "techy" people than do you. Most of the people I know do not use that feature often in Windows 7 [by "that feature", I mean specifically using drag to move window from maximized to restored and moving it]. I personally do use this feature very often, but I still switch tabs much more often--to the point where having no distance makes more sense to me.
Nominating to move from softblocker to hardblocker, since supporting Aero snap functionality is important, and the quick fix of inserting a spacer is pretty straightforward.
blocking2.0: betaN+ → ?
Whiteboard: [softblocker]
Agree with Alex. We went down this rabbit-hole, and should deal with the bigger regressions caused by it, as annoying as they may be.
blocking2.0: ? → betaN+
Whiteboard: [hardblocker]
I don't know if this is possible but I would suggest possibly making the orange firefox button draggable. This way the user still has a target to grab on to and no space above or next to the tabs is lost.
Alex
(In reply to comment #60)
> I don't know if this is possible but I would suggest possibly making the orange
> firefox button draggable. This way the user still has a target to grab on to
> and no space above or next to the tabs is lost.

Sorry, but that makes as much sense as middle-clicking the minimize button to show tab candy. Aero snap works by dragging the glass part of a window, not some orange buttons, and people will expect it to work like this. Additionally the good thing about areo snap is, as explained in comment 49, that you can just blindly throw the mouse against the top of the screen and drag. You can't do that if you need to hit the Firefox button.

I propose to disable Tabs In Titlebar by default and adding an option in the context menu for it.
(In reply to comment #60)
> I don't know if this is possible but I would suggest possibly making the orange
> firefox button draggable. This way the user still has a target to grab on to
> and no space above or next to the tabs is lost.
> Alex

I think we'll end up with lots of people accidentally dragging their window instead of opening up the Firefox menu. And really this is about as good as the spacer approach. Neither holds true to the correct behavior of aero drag.

Overall, I think we're mostly divided into two camps:
1.) People who want tabs in titlebar and don't care about aero drag.
2.) Those who don't want tabs in titlebar and do care about aero drag.

IMHO, they're mutually exclusive features anyways. We shouldn't be trying to shoehorn aero drag into tabs-in-titlebar by using a spacer. We should instead shift focus to bug 624262.
(In reply to comment #59)
> Agree with Alex. We went down this rabbit-hole, and should deal with the bigger
> regressions caused by it, as annoying as they may be.

patch ETA: tonight
(In reply to comment #62)
> Overall, I think we're mostly divided into two camps:
> 1.) People who want tabs in titlebar and don't care about aero drag.
> 2.) Those who don't want tabs in titlebar and do care about aero drag.

I care about both! (What can I say? I'm a demanding user :-)  

I think my (and other) attempts at lateral thinking how to get the best of both worlds weren't a great success. They're getting "too funky". Distinguishing a click from a drag takes time (e.g. waiting for mouse-up), and that breaks the "Firefox must be snappy" criteria. (Did I read 50ms next version? Gosh.)

A glance over at Google Chrome, and I now think it's not purely visual aesthetics that their tabs have diagonal edges, and the [+] (add tab) button has a lot of space around it. These also create extra places you can grab the titlebar. Huh, simple!

I'm about ready to accept the spacer. But, if there's still time, what about just shrinking the [+] button by 3 or 4 pixels? It would obsolete the spacer, and would still be easy to hit because the space includes the monitor edge.
I was worried it might be ugly, but once I see it, I don't think it looks bad.
Attached patch patch (obsolete) — — Splinter Review 
This patch ensures that there is a 12px space between the tabs toolbar and the window caption buttons for window dragging. The UX team has come to the conclusion that this is the best, simple fix for this bug.
Attachment #504510 - Attachment is obsolete: true
Attachment #511691 - Attachment is obsolete: true
Attachment #511722 - Flags: review?(dolske)
Attachment #511722 - Flags: review?(dao)
Whiteboard: [hardblocker] → [hardblocker][has patch][needs review ANYONE]
One of the causes of confusion is that the tabs do not visually touch the top of the screen in maximized mode. This is intentional and matches the Windows 7 theme. Note that the window close button does not touch the right side of the screen and that that start menu orb does not touch the left side of the screen. What makes these controls work is that a user will likely shove the cursor to the corner of the screen and notice that the control is now glowing to indicate that clicking at that location will activate the control, even though the the cursor is not visually on top of the control. The background tabs currently have a hover state, but it is too subtle. By increasing the difference in brightness between the non-hovered and hovered states of the tabs, it becomes much more obvious that a click or drag at the top of the screen will affect a tab, not the window.

The color might be slightly off, but I think that it is more important to get this in first. We can adjust the color if needed in bug 570279.
Attachment #511725 - Flags: ui-review?(faaborg)
Attachment #511725 - Flags: review?(dolske)
Attachment #511725 - Flags: review?(dao)
Comment on attachment 511722 [details] [diff] [review]
patch

>diff --git a/browser/themes/winstripe/browser/browser.css b/browser/themes/winstripe/browser/browser.css
>--- a/browser/themes/winstripe/browser/browser.css
>+++ b/browser/themes/winstripe/browser/browser.css
>@@ -1497,16 +1497,20 @@ richlistitem[type~="action"][actiontype=
> }
> 
> #TabsToolbar:not(:-moz-lwtheme),
> #TabsToolbar[tabsontop=false] {
>   background-image:
>     -moz-linear-gradient(bottom, @toolbarShadowColor@ 1px, rgba(0,0,0,.05) 1px, transparent 50%);
> }
> 
>+#main-window[tabsintitlebar=true] .titlebar-placeholder[type=caption-buttons] {
>+  -moz-margin-start: 12px;
>+}

#main-window[tabsintitlebar=true] isn't needed, as the placeholder isn't visible otherwise. This should be merged with the existing .titlebar-placeholder[type="caption-buttons"] rule, too, and use %ifdef WINSTRIPE_AERO, as we don't need this on XP.
Attachment #511722 - Flags: review?(dolske)
Attachment #511722 - Flags: review?(dao)
Attachment #511722 - Flags: review-
> as we don't need this on XP

If tabs in title bar is supported by Windows XP and there is no actual margin above the tabs then this fix is also required for XP. There is not just the Aero Snap in the titlebar, you can focus and restore the window with it as well (and to me this is still more important as Aero Snap, but seems to be quite ignored in this bug).
Comment on attachment 511725 [details] [diff] [review]
optional patch addendum for more visible background tab hover indication

Completely removing the gradient doesn't feel quite right to me. Anyway, separate bug please.
Attachment #511725 - Attachment is obsolete: true
Attachment #511725 - Flags: ui-review?(faaborg)
Attachment #511725 - Flags: review?(dolske)
Attachment #511725 - Flags: review?(dao)
(In reply to comment #69)
> There is not just the Aero Snap in the titlebar,

... which is what this bug is about.
(In reply to comment #71)
> ... which is what this bug is about.

The bug I created about the title bar access in general got closed as a duplicate of this..
Attached patch patch v2 (obsolete) — — Splinter Review 
My intention for the first patch was to add 12px additional space. I first did it with #TabsToolbar { -moz-margin-start: 12px; }, which was the wrong approach, but Shorlander took a look at the effect and approved the amount of space over IRC. When I went with the correct approach of changing the margin of the placeholder, I forgot that there was already a margin-left: 10px, so really what I wanted to do was change it to margin-left: 22px. That has been done in patch v2.
Attachment #511722 - Attachment is obsolete: true
Attachment #511732 - Flags: review?(dao)
Attachment #511732 - Flags: review?(dao) → review+
Keywords: checkin-needed
Whiteboard: [hardblocker][has patch][needs review ANYONE] → [hardblocker][can land]

        Attachment #511732 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 511725 [details] [diff] [review]
optional patch addendum for more visible background tab hover indication

Moving review over to shorlander since this impacts the visual design of the main window.

        Attachment #511725 -
        Flags: ui-review?(shorlander)

    
    

    
  
Comment on attachment 511725 [details] [diff] [review]
optional patch addendum for more visible background tab hover indication

This has been moved to bug 633521.

        Attachment #511725 -
        Flags: ui-review?(shorlander)

    
    

    
  
Nevermind, I'm too slow(gmail puts review requests and bug comments in to separate threads)

    
  
Whiteboard: [hardblocker][can land] → [hardblocker][can land][has patch]

    
    

    
  
Pushed.

http://hg.mozilla.org/mozilla-central/rev/36c9d7639a7c
Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 13 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [hardblocker][can land][has patch] → [hardblocker]
Target Milestone: --- → Firefox 4.0b12

    
    

    
  
For me this bug hasn't been fixed yet, as it only provides some more space at the sides.

It's needed that you just can go to the top of the screen. Once the Windows 7
titlebar-dragging is adopted by it's user, he gets accustomed to rocket the
mouse to the screen top click and drag.

Needing to look where you aim shouldn't be necessary, it destroys the aim of
the titlebar-dragging. (Which is quickly demaximize the windows and drag it in
place in one move and one reflex)

Current behaviour is annoying once a user is adapted to the windows behaviour in Windows7. It blocks a fluid workflow between different opened windows.

    
    

    
  
I agree with Jan. When I want to switch to maximized firefox window from some other window, I click on top of the window. In FF3 I did this easily. Now I have to look at the top and aim on currently active tab, or I will switch from this tab to another.

    
    

    
  
In my opinion this isn't fixed please bear in mind a lot of people don't have any issue selecting tabs but now have an inability to use aero snap as intended. People who are used to Aero Snap and similar features do not use the top right area very much and it is counter intuitive to have to do so for this functionality especially since every other windows program it would be unnecessary. Surely having to select an area in the top right for simple functions in itself breaks Fitts law.

Without the 1px space I am unable to:
Double tap to take Firefox out of maximize
Drag to left or right to snap to half your monitor (also great for multimonitor)

Please at least add this back in as an option it's removal has ruined my Firefox experience.

    
    

    
  
Don't forget that you have "large" space for dragging the whole window near the Firefox/Mainfield button, it you don't want to go that far on the right near windows buttons :)
Also I don't like Opera like feature in 1px space on the top of the window, because it isn't intuitive and many ppl click there for switching tabs.

    
    

    
  
Large space??? When working in multiple applications, my mouse crashes on firefox/minefield: "oh that's right, here I need some aiming work..."

If firefox conflicts with the workflow of the OS on which it is used, I consider this a rather big issue. Because workflow is what a good browser is about...

The 1px is a good solution: we never banged our mouse-pointer to the screen-top in the past for changing tabs, why we should do it now. The most upper pixels are for the aero snap.
It makes no sense in having the only application in the world conflicting with the aero snap ability...

It's no fun dragging tabs around when not intended, even less if your on auto-pilot and notice to late your mouse is doing something else as intended

    
    

    
  
alternatively: make it 3px instead of 1px above the tabs: it's more visible so users won't accidentally move the window instead of switching or dragging tabs, when they intend to.
As long as it does get fixed some way, it's all right to me. Consequent behaviour of windows in different apps is quite important, if you ask me...

    
    

    
  
I completely agree; I *never* noticed me or anybody else trying to click at the top of the window for changing the tab. I always do it with a quite centralized click on the tab itself, and that's also what the actual interface layout is supporting. I have never seen a button work when clicking on the shadow (the top pixel of the tab is some kind of shadow for me)..

Just restore the previous height of the tabs (I have noticed they got bigger at some previous point) and put that extra space at the top of them. Then you have a clear display that there is *no* hit point for the tab, and everybody is happy.

    
    

    
  
Yes I quite centrally press tabs since your are having to aim horizontally anyway unlike with aero snap where I would select anywhere at the top.

@Virtual_ManPL yes that space is so useful :) I am going to have to do some mouse training exercises

    
    

    
  
For power-users: note you can still drag the little points in between tabs in the top pixel row. It's actually a line about 16(?) pixels wide - note the tab doesn't highlight in this zone. So it's easy to "grab" once you know it. (I often have Winamp covering other places I can normally drag, so this is a life-saver: brilliant!)

For more casual users:
 * People won't notice when they mistakenly overshoot aiming for a tab (refer Comment #54). It's good that it "just works"
 * That extra spacer is important for an intuitive place to grab.
 * You can always turn off tabs-on-top

I reckon the UI team have done well to cover the bases with these design trade-offs. Nice work!

    
    

    
  
Odd, I always click on the top of the screen when I switch tabs ;P
My fiends also when I asked them.

And this "large space is near Firefox/Minefield buttons, it's also near minimize,maximize,close buttons. So it should be enough for you guys I think ;)

    
    

    
  
@Luke sure they would know they overshot the tab it won't be highlighted, it can be a 2 or 3px also not just 1 at the top. Turning off tabs on top is not what people are asking for either and asking people to shoot for a 16px gap between tabs to use aero I doubt appeals to anyone just as spacing to the left or right doesn't. Consider the alternative way round is shooting for a tab say 200px across.

There is surely an argument for either settings to add remove the top spacing or alternatively implement double click on the tabs to do restore/maximize windows behaviour along with dragging tabs doing the snap behaviour. Although I am unsure how the dragging behaviour could be implemented when tab tear off already uses it on the tabs.

    
    

    
  
I am surprised these kind of bugzilla items even exist. One would think such a major release of popular browser should have a detailed specification where this kind of things are strictly defined.
On topic though, sometimes I hit that ~16 pixel wide top pixel row region and sometimes I dont, and tab is switched. I don't like this roulette, this is inconsistent.

    
    

    
  
I've updated to FF4 on my work computer, and I must say it is quite a pain to drag maximized window between two monitors.

    
    

    
  
This bug was fixed at comment 78 by adding empty space before the minimize/windowmode/close buttons.

If you have feedback to give, this is the wrong way to do that, mozilla.dev.application.firefox or mozilla.dev.usability are the right places to discuss the issue.
Most likely nobody will care about comments on closed bugs.

    
    

    
  
Shouldn't this be reopened? It hasn't been verified yet...

    
    

    
  
Verified fixed based on design on Win7.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Status: RESOLVED → VERIFIED

    
    

    
  
I don't get it, it's not fixed, there was just some workaround, and now the bug has been closed... and a new one with exactly the same problem as explained in the initial bug-report needs to be made...

This was: "As the title says, a maximized window with tabs in the titlebar isn't easily dragable when there are many open tabs."

The problem remains... it hasn't become any easier... the few pixels between the FF-flag & the tabs don't make a lot of difference compared to before...
Strange move.... why not just re-open it?

    
    

    
  
(In reply to comment #95)
> The problem remains... it hasn't become any easier... the few pixels between
> the FF-flag & the tabs don't make a lot of difference compared to before...

FWIW, You have to use the space AFTER the tabs, not the one between tabs and the firefox button.

    
    

    
  
yes, I know, but still doesn't help that much... stays a quick fix waiting for something better.

It's contra-intuitive as it is now.
FF should stay intuitive as it has always been.

As some others also pointed out, this detail can become frustrating, as you're used to do this blind in any other application except FF.

How this is best done should be found out (not to create the opposite effect of people wanting to drag a tab ending up dragging a window), but some minimal creativity sure can solve this. (for instance highlighting/shading the pixel-space above the tabs when hovering it, testing out more or less pixelspace above the tabs, ...)

Maybe not the most important thing in the development of FF, but I think it's enough of an annoyance to at least keep the bug open so anyone can look for a fix...

    
    

    
  
Verified fixed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre
Using the space after the tabs, resolves the issue.

    
    

    
  
it has been verified as fixed on 2011-03-23, before that it was unverified.

Seems those not satisfied with the space before, after and in between the tabs are not heard for some reason when that was done...

    
    

    
  
The space before and after the tabs is completely pointless that can go back as tab space for all the difference it makes. The whole idea of the aero features is quick accessibility.

    
    

    
  
While one could make the argument that technically the bug has been resolved because a fix has been implemented, and that means "a maximized window with tabs in the titlebar is isn't easily draggable when there are many open tabs" is no longer the case, in reality I don't think this is true. The titlebar is not _easily_ dragable. It can take 1-2 seconds to get your mouse into the correct position to drag the window. This is an unnecessary waste of time, time that could be easily saved if a better solution were implemented.

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: