Closed Bug 572160 Opened 14 years ago Closed 13 years ago

Put tabs in the title bar when the window is maximized

Categories

(Firefox :: Theme, defect)

All
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 4.0b9
Tracking Status
blocking2.0 --- beta9+

People

(Reporter: Terepin, Assigned: dao)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: ux-efficiency, Whiteboard: [parity-chrome][parity-opera][target-next-beta][d?])

Attachments

(9 files, 17 obsolete files)

1.08 MB, image/png
Details
30.15 KB, image/png
Details
54.17 KB, image/png
Details
5.22 KB, image/png
Details
17.67 KB, patch
Gavin
: review+
Details | Diff | Splinter Review
10.42 KB, image/png
Details
75.65 KB, image/png
Details
7.24 KB, image/png
Details
12.48 KB, image/jpeg
Details
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; sk; rv:1.9.3a6pre) Gecko/20100615 Minefield/3.7a6pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; sk; rv:1.9.3a6pre) Gecko/20100615 Minefield/3.7a6pre

By placing tabs into titlebar users, especially on netbooks, can save vertical space. This feature is higly demanding among users and they are expecting it.
There are several scenarios how to handle this:
1. Chrome/Opera way: Tabs are partially in title bar when window is unmaximized and fully when maximized.
2. Standard (or new, Firefox... go figure): Tabs are fully in title bar when window is maximized and fully out of title bar when window unmaximized.
Personaly, I'd go for number two; it offers an easy way how to switch between two states.

For basic idea how it would look like, see mockup from Stephen (it's picture number two).

We need figure it out how to handle situations:
1. When another items in title bar appears, e.g. edit tray.
2. Tabs should be touching edge of window? If so, how to handle window dragging?
3. Should have tabs same size, or get smaller?

There may be more questions, feel free to write your concerns and ideas.

Reproducible: Always
Blocks: 571785
Depends on: 513162, 513159
Summary: Add option for placing tabs into titlebar → Add option for placing tabs into Title Bar
Attached image App Button in Title Bar mockup (obsolete) —
This should be a discussion on the discussion groups rather than a bug. It's
been mentioned that placing tabs in the title bar might not be feasible due to
UI plans (i.e. form controls and sync (weave) controls) and as such would be
revisited after their landing, notably not before 4.0 final.

I could be wrong but that was the impression I got.
By default we'll want to go with option 2 (normal window tabs don't touch the title bar, maximized window they go all the way to the screen edge).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Copying comments over from duped bug:

On windows Vista and Windows 7, the tab strip should be placed at the very top
of the window (against the screen edge) when the window is maximized.  This
gives us major a fitts's law win for tab switch operations.

Something that we will need to decide on 7 is if drag operations should do a
restore down on the window as a whole, or do a tab tear off on the particular
tab being dragged out.

On XP the menu bar should be against the screen edge, although that's a
separate follow up bug.
Keywords: ux-efficiency
Peter: can we adjust the the summary to indicate the maximized default (I overlooked this because I thought it was solely about the normal state option)
Attachment #451318 - Attachment is obsolete: true
Summary: Add option for placing tabs into Title Bar → Add option for placing tabs into Title Bar when window is maximized
Alex, could you comment Bug 571785?
Can we get a pref for this behaviour, please?

I'm on Win7, and I'm a bit concerned that this feature (as you alluded to in comment #6) will detract from the usability improvements made to the window manager.

Drag-restore + Aero-snap is rather useful, and taking away the title bar could make it difficult to use -- you're either going to have to compromise on the DWM or the tab dragging, which are both great features.

Might also want to consider the impact on touch-screens; we're starting to see some manufacturers jumping onto this train, and reducing the window chrome in either max or restored size will make life harder for these users.

Perhaps have it off by default except on low-res screens?
That is why it's being called "Add OPTION for placing tabs into Title Bar when window is maximized" you know.
>Drag-restore + Aero-snap is rather useful

we haven't made a final call on this, but I'm leaning towards drag operations acting on the window as a whole (aero-snap) when maximized, instead of creating tear off tabs.  If the user is running in maximized mode, It seems like they are more likely to want to switch back down to window mode before they want to start creating secondary windows through tab tear off (which themselves would not be maximized).
Ideally, I think a tab drag should trigger Aero-snap when the tab is dragged to the screen edges -- effectively letting you tile content side-by-side in one movement.

Whilst I agree that tab tear-off is more likely on a single screen with a maximized window, it'd be a shame to lose the ability to drag a tab across onto a second monitor, as you can now.

Also worth considering whether there might be any consistency problems with middle/right-click behaviour with the window in each state.
Adding option for putting tabs into Title bar when window is maximized is a good thing, but you also need to decide which one is the default mode for Firefox 4. 

Should tabs be placed into title bar or tabs not to be placed in title bar when win is maximized be the default mode for Firefox 4? 

I suggest different platforms have different default mode. 

Example: Windows Vista/7 have tabs in titlebar as default 
Windows Xp tabs not in titlebar as default.  

This is only an example. I hope devs and the community discuss about this before deciding which choice to be the default mode for Firefox 4.
The following Stylish userstyle will now put the tabbar up into the titlebar in the recent hourlies. It overflows with the window controls if you have more than a few tabs open, but that could be taken care of.

@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);

#appmenu-button-container{
position: fixed !important;
}

#navigator-toolbox[tabsontop="true"] #TabsToolbar{
padding-left: 95px !important;
}

#appmenu-button{
padding: 3px 9px 3px 9px !important;
height: 22px !important;
}
Working good.
>Example: Windows Vista/7 have tabs in titlebar as default 
>Windows Xp tabs not in titlebar as default.  

XP has a menu bar (interactive consistency with the rest of the platform), but I think we should go ahead and move the menu bar to the top of the screen in that case.  Tab's don't get the fitts's law win, but not much else we can do aside from removing the menu bar.
Shouldn't we also have an option about the menu bar at the title bar or not? 

Although I think that option like this one(bug 572160) should be located in the Options... Menu of of Firefox. 

Alex is the Firefox 4 Options being rewritten?
Is the new orange Firefox not an ideal target for Aero-snap dragging?
(In reply to comment #18)
> Is the new orange Firefox not an ideal target for Aero-snap dragging?

I was thinking exactly the same yesterday - just about to post it but you beat me to it! It is indeed logical that dragging the new Firefox Menu button button should also drag the window as it is supposed to be a global menu. The button is also large enough to drag on a touch screen. This would also give Firefox a UI-design leg-up over Chrome which in full screen (while excellent with tabs on the extreme top) has no large area like this that is always guaranteed to be available for drag-to-restore.

To be consistent with this and the behaviour of standard window glass, and for those not on Windows 7, I propose that a double-click gesture on the Firefox Menu button should also restore/maximize the window. (NOT to close the window as others have suggested - that close gesture is a relic from Windows 3 and not needed as the close button already has the Fitts' advantage of being in the top-right of the window). Double-clicking on a tab would also restore/maximize the window and switch to that tab.

I would also propose that right-clicking on the Firefox Menu button (or on any free glass in the titlebar - something that is not working right now) should show the standard system menu.
For what it's worth, Windows Live Movie Maker wave 3 and wave 4 draw items into the titlebar (more than just the save/copy/paste buttons). When you add a video file do the project and select it in the timeline, a "Video Tools" button pops up in the titlebar. Clicking that button selects the "Edit" tab of the ribbon UI. Click/drag on the button moves the window around, as if the user had click/dragged from the titlebar itself. It snaps/unsnaps just like the regular titlebar.
(In reply to comment #20)
> For what it's worth, Windows Live Movie Maker wave 3 and wave 4 draw items into
> the titlebar (more than just the save/copy/paste buttons). When you add a video
> file do the project and select it in the timeline, a "Video Tools" button pops
> up in the titlebar. Clicking that button selects the "Edit" tab of the ribbon
> UI. Click/drag on the button moves the window around, as if the user had
> click/dragged from the titlebar itself. It snaps/unsnaps just like the regular
> titlebar.

Can you add an attachment screenshot?
Attached image Windows Live Movie Maker (obsolete) —
This is the non-maximized version.

When it's maximized, the button uses the full height of the titlebar.
(In reply to comment #22)
> Created an attachment (id=456201) [details]
> Windows Live Movie Maker
> 
> This is the non-maximized version.
> 
> When it's maximized, the button uses the full height of the titlebar.

These buttons are in almost every ribbon application in Windows 7/Office 2007/Office 2010. Notably in Office 2010 (no idea about 2007) the window is not draggable from this button area as it is in Movie Maker. The fact that in Movie Maker the title bar is still draggable when overlayed by a clickable element would be a good sign that it would indeed be possible to also be able to drag the window from the Firefox Menu button.
(In reply to comment #18)
> Is the new orange Firefox not an ideal target for Aero-snap dragging?

Allowing the window to be dragged by dragging the Firefox button also allows tabs to be moved and tear-off tabs to be created when the window is maximized.

Another alternative would be to only allow the tabs to be moved/tore-off if the right/middle mouse button is used, however, I think the former solution is much more elegant.
>Is the new orange Firefox not an ideal target for Aero-snap dragging?

A lot of users will click and drag down to access the contents of the menu itself, and then on upclick we activate the menu command.  Some people use this hold and upclick pattern for all menu interactions (and it does save a whole extra downclick).
(In reply to comment #25)
> >Is the new orange Firefox not an ideal target for Aero-snap dragging?
> 
> A lot of users will click and drag down to access the contents of the menu
> itself, and then on upclick we activate the menu command.  Some people use this
> hold and upclick pattern for all menu interactions (and it does save a whole
> extra downclick).

I had thought of that problem.

If you keep the Firefox Menu as a standard boring grey menu then it makes sense to still allow dragging to access the menu, however, if you make a more snazzy graphical menu then you can get away with only allowing the two downclicks. In MS Word 2010 the 'File' menu will not allow this click-and-drag menu selection - you must perform 2 downclicks.

For example:
https://wiki.mozilla.org/Talk:Firefox/4.0_Windows_Theme_Mockups#An_idea_for_the_App_button
In a matrix arragement like this and with sub-menu controls like the zoom option and other layered drop-down menus within the menu ('Print' and 'encoding' buttons for example) it would mean that dragging to select would not cross the user's mind and performing the two down-clicks would be the most natural operation.
Requesting to block beta3+, as the code freeze for beta2 is too close to land this. There are some CSS styles that do this already.
blocking2.0: --- → ?
beltzner: I think this should block final release.  Big efficiency win, more screen space for content for users on netbooks, and also our #1 request over at user voice: http://firefox.uservoice.com/forums/57440-firefox-4-beta/suggestions/888045-tabs-on-same-row-as-firefox-button?ref=title
Alex, I think it would be better if this feature be released earlier say in beta 3, so that users can give more feedback about this feature. If this is only released in Final Firefox 4, users who dislike the feature or its design or have comments about it may not have enough opportunity to give feedback.
right, I meant that at a minimum this should block final.
Sorry that I misunderstood you. Alex, do you have any nice idea/suggestion about where to put the page title when the tabs are in the Title Bar.

I believe that putting a page title in the title bar when Tabs in the Title Bar will be problematic. It may look weird, ugly and out of place if not done properly. 

Here is some Idea that I have come up with: 

We can do Either
1) Do not put page title at all when Tabs in Title Bar, keep current Firefox behavior.

2) Do not put additional Page title in Title bar but make Active Tab expand outward so that all of its page title is visible even if Tab Overflow.

3) Put full or summarized Page title beside the Firefox Button(which has turn into an icon)

4) Put full or summarized Page title into the Firefox Button beside the Firefox Icon.

Or

5) Show the Full Page title in the Location Bar of the Tab.

I admit all of them will make Firefox look different and maybe to some people weird, but these are all the ideas that I can think of.
Put full or summarized Page title beside the Firefox Button(which has turn
into an icon)
Put full or summarized Page title beside the Firefox Button(which has turn
into an icon)
Blocks: 581899
If it will have a title, it's gotta be on the top, (in windows) either all the way on the left (next to firefox icon, but it can't have anything else up there), or in the center. What I personally want is that the tabs stay below the title bar, and the title is in the center on top (see bug 575487). However, it would be nice if there would be an option (in "Menu" > options > tabs) to hide the title, and place the tabs there instead.
I honestly don't see why we need a title when tabs already show it. That's rather redundant.
If you can't live without always seeing the page title
1. Don't hide the menu bar
or 
2. Wait until an addon's created.

There's no reason to include the page title when the menu's disabled.
(In reply to comment #36)
> I honestly don't see why we need a title when tabs already show it. That's
> rather redundant.
> If you can't live without always seeing the page title
> 1. Don't hide the menu bar
> or 
> 2. Wait until an addon's created.
> 
> There's no reason to include the page title when the menu's disabled.

Its not about redundancy Taz, its about the fact that you cannot read the entire tab name, the title provides all the string data, and titlebar text has always been helpful when having many applications open, if your a real developer, you might have 20 program windows open at once all day long.
>Its not about redundancy Taz, its about the fact that you cannot read the
>entire tab name, the title provides all the string data, and titlebar text has
>always been helpful when having many applications open, if your a real
>developer, you might have 20 program windows open at once all day long.

The only problem with a tab title is that is is displayed shorter than it is in the title bar. However, the only case when you really use the title in the title bar is when you can see the actual window, and in this case you can see the content of the window as well. If you are switching between the windows using alt-tab or taskbar, the title is not truncated.
How's about we just make it customizable? see bug 583959. Although the default should be with the tabs in the title bar when maximized.
Depends on: 583959
OS: Windows 7 → All
Hardware: x86 → All
Version: unspecified → Trunk
Jimm - what kind of code risk does this represent? Helps us understand whether to debate the value of the UI on its merits, or just turf it as infeasible.
(In reply to comment #40)
> Jimm - what kind of code risk does this represent? Helps us understand whether
> to debate the value of the UI on its merits, or just turf it as infeasible.

We can put anything up there we want really, it's just content. The client area now stretches all the way to the top of the window chrome, excluding window border padding on each side. (we could get rid of that too if we wanted.)

The one thing we have to be careful about is staying out of the way of the caption buttons on aero desktops. I think we're leaning toward clipping content around them to deal with the personas bug. We'd have to expose some aero caption button position info so we could avoid them. Which shouldn't be a problem.
According to this: http://limi.net/articles/firefox-ux-team-update-19/ this is suppose to be in beta4 and code freeze in two days, but it doesn't have even assigne. I take it won't be in beta4... (And many users want this feature.)
Puts tabs in titlebar when maximized as show in the mockup.
I found some userstyle and I think it works quite good, maybe can help. I see one problem with background in menu bar and second with enabled menu bar and tabs on top.

        window:not([inFullscreen]) #navigator-toolbox[tabsontop="true"] #TabsToolbar {
        margin-top: -22px !important;
        -moz-box-ordinal-group: 1 !important;
    }

window:not([inFullscreen])[sizemode="normal"] #navigator-toolbox[tabsontop="true"] #TabsToolbar {
        padding-left: 2px !important;
        padding-right: 103px !important;
        padding-top: 25px !important;
    }
window:not([inFullscreen])[sizemode="maximized"] #navigator-toolbox[tabsontop="true"]  #TabsToolbar {
        padding-left: 97px !important;
        padding-right: 107px !important;
    }
window:not([inFullscreen]) #navigator-toolbox[tabsontop="true"]
        #toolbar-menubar[autohide="true"]:not([inactive]) {
        -moz-box-ordinal-group: 2 !important;
        -moz-appearance: toolbox !important;
        margin-left: 1px !important;
        margin-right: 1px !important;
    }  
window:not([inFullscreen]) #navigator-toolbox[tabsontop="true"]
        #toolbar-menubar[autohide="true"]:not([inactive]) * {
        color: black !important;
    }
#appmenu-button
{
padding: 2px 13px 4px 12px !important;
}
(In reply to comment #44)
> I found some userstyle and I think it works quite good, maybe can help. I see
> one problem with background in menu bar and second with enabled menu bar and
> tabs on top.
> 
>         window:not([inFullscreen]) #navigator-toolbox[tabsontop="true"]
> #TabsToolbar {
>         margin-top: -22px !important;
>         -moz-box-ordinal-group: 1 !important;
>     }
> 
> window:not([inFullscreen])[sizemode="normal"]
> #navigator-toolbox[tabsontop="true"] #TabsToolbar {
>         padding-left: 2px !important;
>         padding-right: 103px !important;
>         padding-top: 25px !important;
>     }
> window:not([inFullscreen])[sizemode="maximized"]
> #navigator-toolbox[tabsontop="true"]  #TabsToolbar {
>         padding-left: 97px !important;
>         padding-right: 107px !important;
>     }
> window:not([inFullscreen]) #navigator-toolbox[tabsontop="true"]
>         #toolbar-menubar[autohide="true"]:not([inactive]) {
>         -moz-box-ordinal-group: 2 !important;
>         -moz-appearance: toolbox !important;
>         margin-left: 1px !important;
>         margin-right: 1px !important;
>     }  
> window:not([inFullscreen]) #navigator-toolbox[tabsontop="true"]
>         #toolbar-menubar[autohide="true"]:not([inactive]) * {
>         color: black !important;
>     }
> #appmenu-button
> {
> padding: 2px 13px 4px 12px !important;
> }

Joshua M has done the CSS bit in the patch he uploaded, I think it's merely a matter of adding the prefs and UI now.
(In reply to comment #31)
> Sorry that I misunderstood you. Alex, do you have any nice idea/suggestion
> about where to put the page title when the tabs are in the Title Bar.
> 
> I believe that putting a page title in the title bar when Tabs in the Title Bar
> will be problematic. It may look weird, ugly and out of place if not done
> properly. 
> 
> Here is some Idea that I have come up with: 
> 
> We can do Either
> 1) Do not put page title at all when Tabs in Title Bar, keep current Firefox
> behavior.
> 
> 2) Do not put additional Page title in Title bar but make Active Tab expand
> outward so that all of its page title is visible even if Tab Overflow.
> 
> 3) Put full or summarized Page title beside the Firefox Button(which has turn
> into an icon)
> 
> 4) Put full or summarized Page title into the Firefox Button beside the Firefox
> Icon.
> 
> Or
> 
> 5) Show the Full Page title in the Location Bar of the Tab.
> 
> I admit all of them will make Firefox look different and maybe to some people
> weird, but these are all the ideas that I can think of.

Regarding this problem with the page title - there is a thread with links to mock-ups of both options 2 and 5 that you mention here:
http://groups.google.com/group/mozilla.dev.usability/browse_frm/thread/d5290d18ae19c3f2#
With regards to the problem of allowing the Windows 7 drag-to-restore gesture with the tabs in the title bar (important for touch-screens), I have another suggestion. How about making a drag on an inactive tab also drag the titlebar? Dragging the active tab would re-order the tab's position as normal.

This wouldn't even make much perceived difference to the current tab reordering behaviour as currently an inactive tab that you try to re-order becomes active as soon as you click on it to start dragging.

(Though I still prefer the idea behind allowing the menu button to be draggable - the logic of the menu button being the "global" control is nice. However, dragging an inactive tab on the titlebar may be more familiar behaviour to the user).
(In reply to comment #47)

Can't do that. It'd interfere with tear off tabs and switching tabs behavior.
This would most certainly make a perceivable difference. Tabs are meant to be reordered and dragged, not to be window anchors. 

A better idea would be to make the blank spaces between buttons in the navigation/bookmark bars draggable. 

Making the menu button draggable seems like a good idea although some problems could arise.
> Can't do that. It'd interfere with tear off tabs and switching tabs behavior.
> This would most certainly make a perceivable difference.

I don't like that word "can't" - of course it can be done!! :). OK, maybe there might be a slight perceivable difference if you want to tear off the tab, rather than just re-ordering it. However, it isn't such a big deal to switch to the tab before tearing it off, considering you are already automatically switched to that tab (and switched to the new window) after it has been torn off.


> Tabs are meant to be
> reordered and dragged, not to be window anchors.

Yes, but now they are in the title bar, therefore the user will also expect title-bar behaviour here.

 
> A better idea would be to make the blank spaces between buttons in the
> navigation/bookmark bars draggable. 

There isn't really any space here! Maybe it is ok with a mouse, but with a big finger on a touch screen that's going to be impossible!


Not a biggie, however, one other disadvantage of the drag-inactive-tab-to-restore behaviour is that it could be slightly difficult to perform on a laptop touchpad, especiallly if using the Synaptics "Tap and Drag" gesture rather than the dedicated left-click button below the touchpad. You would end up making the inactive tab active before you could drag it! (no such problems with dragging the Firefox Menu button though - perhaps implement both?!).
(In reply to comment #49)
Another disadvantage is that it might mean that you would need both a down-click and an up-click to switch tabs - not desirable as could make switching tabs feel slower. Perhaps there are some clever drag/timing detection methods that could be implemented?
(In reply to comment #50)
... though, while not desirable, having to have both a down-click and up-click to switch tabs isn't such a big deal - in fact if you tap on a laptop touchpad then this is the easiest form of click to perform
(In reply to comment #51)
... notably, the Windows 7 Taskbar also requires both a down-click and up-click to switch windows. I think it's worth the trade-off.
Ideally tabs in the title bar should leave some space to allow user to drag Titlebar.
The following clarification is from IRC (I hope limi doesn't mind me reposting it here):
[17:17]	<limi> so the behavior should be...: on Windows: put tabs in the title bar when in Maximized mode. On Mac, allow it as an opt-in, since it doesn't have maximize in the same way. On both platforms it should be possible to explicitly opt into it, but it's not the default (unless you're maximized on Windows).
(In reply to comment #47)
> With regards to the problem of allowing the Windows 7 drag-to-restore gesture
> with the tabs in the title bar (important for touch-screens), I have another
> suggestion. How about making a drag on an inactive tab also drag the titlebar?
> Dragging the active tab would re-order the tab's position as normal.
> 
> This wouldn't even make much perceived difference to the current tab reordering
> behaviour as currently an inactive tab that you try to re-order becomes active
> as soon as you click on it to start dragging.

Another advantage of this behaviour is that it already fits in very nicely with the FF4 styling in Windows 7/Vista. Inactive background tabs are already styled as Aero glass, which would therefore already visually imply that they could drag the window.

Overall, I think this is the best solution for Win7 drag-to-restore. Dragging the Menu button is logically very nice too, but is perhaps a bit too unconventional.
Really-really-want, but given the problems we've had with drawing in the titlebar, I can't see us block on this.
blocking2.0: ? → -
I'd like to re-nominate this if I can — part of the reason behind having tabs on top was the ability to do this when the window is maximized on Windows. It's one of the most persistent requests via Firefox Input and our other channels (lists, Uservoice), as well as being something people really like about Chrome.

Furthermore, if we do this, our UI is actually *more* space-efficient than Chrome on Windows. In itself, that's not a goal, but it does send the right message, that we do care about browsing screen real estate.

Even if we have to reduce the scope and drop the functionality of making it optionally available on other platforms like OS X, I think this should block for Windows at least — then we can make it happen on other platforms in a 4.x release.

Jim indicated in comment 41 that it shouldn't be very hard — and while I sympathize with the "anything touching the tab browser is hard" sentiment, I feel that putting tabs on top and not allowing them to use the titlebar when maximized feels unfinished, and is a halfway house.

Jim, can you comment on your availability and the feasibility of this in light of the revised beta schedule?
blocking2.0: - → ?
Whiteboard: [parity-chrome]
Sorry, I was confused as to which parts Jim was involved with.

I guess Dao or Gavin would be the right people to ask what it would take to get Joshua's patch to work the way we want:

* on Windows: put tabs in the title bar when in Maximized mode. 

Optionally (but not required):
* On Mac, allow it as an opt-in, since it doesn't have maximize in the same way. On both platforms it should be possible to explicitly opt into it, but it's not the default (unless you're maximized on Windows).
Comment on attachment 465999 [details] [diff] [review]
Tabs in titlebar when maximized v1

requesting for limi - Dao, thoughts what it would take to finish this up and land it?
Attachment #465999 - Flags: feedback?(dao)
Attachment #465999 - Flags: feedback?(gavin.sharp)
Comment on attachment 465999 [details] [diff] [review]
Tabs in titlebar when maximized v1

Does this still work now that bug 575870 relanded?
Attachment #465999 - Flags: feedback?(dao)
Comment on attachment 465999 [details] [diff] [review]
Tabs in titlebar when maximized v1

You're using a lot of [element]:<pseudo-selector> [element]

This is generally not accepted css. You want to boil down as much as you can to the final element with child selectors, e.g.:

#main-window > #titlebar > #titlebar-content > #appmenu-button-container

This helps with style resolution by keeping the declarations localized to a specific element.
CC'ing in Joshua M since comments are now being directed at him.
(In reply to comment #62)
> CC'ing in Joshua M since comments are now being directed at him.

Oh, weird — didn't know you could attach a patch and *not* be added to CC. Thanks!
(In reply to comment #60)
> Comment on attachment 465999 [details] [diff] [review]
> Tabs in titlebar when maximized v1
> 
> Does this still work now that bug 575870 relanded?

Seeing how others CSS styles with the same purpose is failing to do so, I'll gues no.
(In reply to comment #64)
> (In reply to comment #60)
> > Comment on attachment 465999 [details] [diff] [review] [details]
> > Tabs in titlebar when maximized v1
> > 
> > Does this still work now that bug 575870 relanded?
> 
> Seeing how others CSS styles with the same purpose is failing to do so, I'll
> gues no.

Have you tested it? What's wrong with the failing code?
I dunno, I only saw other user's reports from Mozillazine forums.
(In reply to comment #65)
> Have you tested it? What's wrong with the failing code?

When 575870 first landed, my userscript for pushing tabs into the titlebar had the tabbar drawn under the titlebar, blocking the tabs from view.

When it relanded, my userscript draws the tabbar over the titlebar, but clicking/hovering in the titlebar's area does not get passed down to the tabs (eg, on hover over an unselected tab, the tab does not change color/opacity). You have to hover/click on part of the tab below the titlebar for those events to work.

I read somewhere that some other userscripts DO work up there, but I haven't had a chance to test them.
Limi: I understand the rationale for wanting this, and it would be lovely, yes, and good for notebooks. It's not a blocking issue for Firefox 4, though.

I would be fine taking a Windows-only fix, and if a reviewed patch appears, someone should prod me to approve it.
blocking2.0: ? → -
(In reply to comment #67)
> (In reply to comment #65)
> > Have you tested it? What's wrong with the failing code?
> 
> When 575870 first landed, my userscript for pushing tabs into the titlebar had
> the tabbar drawn under the titlebar, blocking the tabs from view.
> 
> When it relanded, my userscript draws the tabbar over the titlebar, but
> clicking/hovering in the titlebar's area does not get passed down to the tabs
> (eg, on hover over an unselected tab, the tab does not change color/opacity).
> You have to hover/click on part of the tab below the titlebar for those events
> to work.
> 
> I read somewhere that some other userscripts DO work up there, but I haven't
> had a chance to test them.

Does that mean it's impossible to do without all the pseudo selectors as per comment 61?
(In reply to comment #69)
> Limi: I understand the rationale for wanting this, and it would be lovely, yes,
> and good for notebooks. It's not a blocking issue for Firefox 4, though.
> 
> I would be fine taking a Windows-only fix, and if a reviewed patch appears,
> someone should prod me to approve it.

OK, I still consider this a blocker as far as UX is concerned. We're already drawing in the title bar, I don't understand why this would be a lot more complicated.

Dao, Gavin — any advice to offer on the code complexity of such a fix?
(In reply to comment #71)
> Dao, Gavin — any advice to offer on the code complexity of such a fix?

I'm neither of these people, but just from my own experience doing this with Stylish, unless an element is styled position: fixed, it won't respond to click/hover events up in the titlebar.
(In reply to comment #71)
> OK, I still consider this a blocker as far as UX is concerned. We're already
> drawing in the title bar, I don't understand why this would be a lot more
> complicated.

It's nothing to do with complexity, blocking status reflects what we would not ship the product without having fixed. The bugs cleaning up the (as yet incomplete) work that allows us to draw into the title bar are blocking. This issue is an extremely nice to have, but not a blocker.

On the topic of complexity, though, we can try to think through the full design. The mockup doesn't indicate where the menuBar would render when ALT is pressed - between the button and the tabstrip?

(I agree that it's a high value UX polish priority, and as I said, an especially big win on netbooks. :)
> The mockup doesn't indicate where the menuBar would render when ALT is
> pressed - between the button and the tabstrip?

Surely Alt should just activate the new menu button (like in Opera 10.6)? Alt-F is a bit too FF specific (do we want Opera to change their menu to Alt-O and IE to Alt-I? making switching browsers all the more difficult). The fact that Alt activated the old menu in IE7 was a sign of bad new menu design - if the new menu is designed well then users will never ever want to see the old menu again.
(In reply to comment #73)
> (In reply to comment #71)
> > OK, I still consider this a blocker as far as UX is concerned. We're already
> > drawing in the title bar, I don't understand why this would be a lot more
> > complicated.
> 
> It's nothing to do with complexity, blocking status reflects what we would not
> ship the product without having fixed. The bugs cleaning up the (as yet
> incomplete) work that allows us to draw into the title bar are blocking. This
> issue is an extremely nice to have, but not a blocker.

FWIW, the work enabling drawing in the titlebar is complete. Everything from the lower content area border to the upper window frame border is now being rendered in content on all windows platforms.
(In reply to comment #73)
> This issue is an extremely nice to have, but not a blocker.

Consider this:
Users will burn Mozilla into ashes if Firefox will not have this feature.
You mark my words on that.
(In reply to comment #74)
> > The mockup doesn't indicate where the menuBar would render when ALT is
> > pressed - between the button and the tabstrip?
> 
> Surely Alt should just activate the new menu button (like in Opera 10.6)? Alt-F
> is a bit too FF specific (do we want Opera to change their menu to Alt-O and IE
> to Alt-I? making switching browsers all the more difficult). The fact that Alt
> activated the old menu in IE7 was a sign of bad new menu design - if the new
> menu is designed well then users will never ever want to see the old menu
> again.

You are SO wrong. First of, Alt temporary show Menu Bar. Second, purpose of FXM was never to replace the Menu bar, but to group the most used items in it. That is a HUGE difference. Learn how things work before you state something like that as it is was true.
(In reply to comment #77)
> Learn how things work before you state something like
> that as it is was true.

There's really no need for that. I don't see the need for two menus myself and look forward to the day you can turn the old one off completely.
Firefox is about choices. Of course, I could write many more reasons why to keep old menu, but this surpass everything else.
(In reply to comment #76)
> (In reply to comment #73)
> > This issue is an extremely nice to have, but not a blocker.
> 
> Consider this:
> Users will burn Mozilla into ashes if Firefox will not have this feature.
> You mark my words on that.

Okay, they're marked. Bugzilla is not the place for advocacy, and this comment is not constructive.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
My intention wasn't to make my comment feels advocate, but dramatic.
I'm seriously serious about this. Users want it. Badly. Using CSS to achieve this is *not* user friendly. Plus Chrome and Opera have this already. If FX4 will not have this feature, it will hurt Firefox's reputation *a lot*. And there will be lost of existing and possibly new users, you can count on that.
I'm not telling this because I want to insult you, but because i *care* about Firefox. My advice is based every day reading of users comments across many sites. It isn't something that I came up just for making fun from you.
I'm sorry if don't see it this way.
Regardless of playing catch up or how many users want it, this bug hasn't got an owner. If you can make the patch or no someone else that has and wants to own it then get them to speak up, but as things currently stand, without an owner or working patch, this is unachievable and the paid staff are sadly otherwise occupied.
Let's everyone please return to on-topic conversation, and avoid advocacy comments. That the bug hasn't been WONTFIXED means that it's still a going concern, just looking for an owner. That it hasn't been marked as a blocker means that we will ship Firefox 4 without it; that decision has been made twice now, and unless new *information* (not opinion!) can be brought to bear, it is unlikely to change. If a patch comes along, I will gleefully approve it.
Joshua M said he will take a look at this. Yay!
Assignee: nobody → soapyhamhocks
Attachment #465999 - Attachment is obsolete: true
Attachment #465999 - Flags: feedback?(gavin.sharp)
Attachment #470622 - Flags: review?(dao)
Comment on attachment 470622 [details] [diff] [review]
Tabs in titlebar when maximized v2

The menu toolbar needs an end padding as well, as it can contain arbitrary content.

It looks like the padding for the tabs toolbar is going to be wrong with the menu bar not being hidden.

What are the em values based on?

What about aero basic?
Attachment #470622 - Flags: review?(dao) → review-
>On the topic of complexity, though, we can try to think through the full
>design. The mockup doesn't indicate where the menuBar would render when ALT is
>pressed - between the button and the tabstrip?

whatever is easiest to implement, a temporary row above everything would be fine.
Right now, I'm using a custom stylesheet to push the tabbar up into the titlebar.

Pressing ALT makes the menubar appear underneath the tabbar.

Looks good to me, although it might need a bit of different styling to blend into the navbar better?
Comment on attachment 470622 [details] [diff] [review]
Tabs in titlebar when maximized v2

I think the Fx button next to the tabs is little bit weird with your patch. There is too much space beetween the Fx button and nav-toolbar. 

You can increase the height of the Fx button or move up the nav-bar and tabbar.

Each way has some negatives...
Comment on attachment 470622 [details] [diff] [review]
Tabs in titlebar when maximized v2

And another issuse.

I cant click on the tabs if i click above the tab buttons!

It would make clicking tabs much more easy, see Faaborg's mockup:

http://people.mozilla.com/~faaborg/files/20100625-tabsOnTop/mouseInfinity.png
(In reply to comment #90)
> Comment on attachment 470622 [details] [diff] [review]
> Tabs in titlebar when maximized v2
> 
> And another issuse.
> 
> I cant click on the tabs if i click above the tab buttons!

May I suggest tabs that reach the top of the screen (for targeting WIN) and then keep a dragable area between the tabs and the window controls, perhaps 30 px wide?
(In reply to comment #91)
> (In reply to comment #90)
> > Comment on attachment 470622 [details] [diff] [review] [details]
> > Tabs in titlebar when maximized v2
> > 
> > And another issuse.
> > 
> > I cant click on the tabs if i click above the tab buttons!
> 
> May I suggest tabs that reach the top of the screen (for targeting WIN) and
> then keep a dragable area between the tabs and the window controls, perhaps 30
> px wide?

Do people drag windows out of a maximised state often? I think I'd prefer if this used all the space available. Especially considering we'll have the sync UI up there.
Whiteboard: [parity-chrome] → [parity-chrome][parity-opera]
Depends on: 592210
(In reply to comment #92)
> Do people drag windows out of a maximised state often? I think I'd prefer if
> this used all the space available. Especially considering we'll have the sync
> UI up there.

With Windows 7 I'm guessing quite a few people are dragging windows right and left for the "snap" feature which re-sizes to half the screen width.
(In reply to comment #93)
> (In reply to comment #92)
> > Do people drag windows out of a maximised state often? I think I'd prefer if
> > this used all the space available. Especially considering we'll have the sync
> > UI up there.
> 
> With Windows 7 I'm guessing quite a few people are dragging windows right and
> left for the "snap" feature which re-sizes to half the screen width.

But the question remains, is this in maximised mode? In windowed mode, it takes care of itself as designed. In maximised mode however, I'm not sure there is the necessity.
(In reply to comment #94)
> But the question remains, is this in maximised mode? In windowed mode, it takes
> care of itself as designed. In maximised mode however, I'm not sure there is
> the necessity.

Well, I have no usage data obviously, but yes it is possible to drag from maximized to left and right. I'd guess it is as common as dragging un-maximized winows.
With current patch, the pop-up windows are messed up. The nav-bar is moved to title bar, so the caption buttons and Fx button cover it.

Or i do something badly?
It was me, sorry...
(In reply to comment #92)
> Do people drag windows out of a maximised state often?

We need to have some space for dragging, but that doesn't mean we shouldn't support *clicking* in that "invisible" area. Dragging in that area will of course drag the window itself, but it should be possible to miss the tab by a few pixels (all the way to the top for the Fitts' win) when clicking.

Windows Vista/7 finally fixed it so that you can drag maximized windows, and we should support that. :)
>Windows Vista/7 finally fixed it so that you can drag maximized windows, and we
>should support that. :)

Yes, to reiterate since there are a lot of comments in this bug, we want to support aero snap over tab tear off in 7 when in the maximized state.
(In reply to comment #99)

Funny...I just filed bug 592450 about that some odd hours ago.
(In reply to comment #99)
> >Windows Vista/7 finally fixed it so that you can drag maximized windows, and we
> >should support that. :)
> 
> Yes, to reiterate since there are a lot of comments in this bug, we want to
> support aero snap over tab tear off in 7 when in the maximized state.

Did you guys consider allowing both as suggested in comment #47? Here's a mock-up to try and illustrate what I meant a bit clearer.
(In reply to comment #101)
> Did you guys consider allowing both as suggested in comment #47? Here's a
> mock-up to try and illustrate what I meant a bit clearer.

Yes, we did. It'll introduce "magical" (changing) behavior, and is a classic recipe for mode errors. :)
(In reply to comment #102)
> (In reply to comment #101)
> > Did you guys consider allowing both as suggested in comment #47? Here's a
> > mock-up to try and illustrate what I meant a bit clearer.
> 
> Yes, we did. It'll introduce "magical" (changing) behavior, and is a classic
> recipe for mode errors. :)

good to check :) though the behaviour does change in correspondence to the appearance i.e. Aero glass vs. non-Aero-glass.
> the behaviour does change in correspondence to the
> appearance i.e. Aero glass vs. non-Aero-glass.

... therefore allowing you to argue that this is not a "modal" interface at all: http://en.wikipedia.org/wiki/Mode_%28computer_interface%29#Modes_and_Awareness

The glassy background tabs can be logically considered (and visually indicated as) part of the window itself, therefore act as a standard window. The non-glassy foreground tab can be logically considered (and visually indicated as due to the continuous light colour that bleeds into the toolbar) as part of the application window's *application content* and be logically treated in an application-specific way.

I'm also not sure *how* annoying this would be if the user got it wrong (user trials?). IMO it's not a particularly big deal if the window is moved instead of the tab re-ordered or vice-versa - they're fairly similar behaviours that are easy to undo by dragging the mouse cursor back to its drag origin before letting go of the mouse button.
I have a slight concern I'd like to make sure is being considered with this bug. For me, the ability to place buttons in the title bar is one I'm really looking forward to and hope it actually happens, will this patch have some way of acknowledging that and thus not overlapping said buttons?
-Added moz-padding-end to menubar
-Fixed TabsToolbar position when menubar was active.
-Changed tabview/ui.js to set inTabView attribute on main window, helps with position:fixed code on #titlebar.
-Em values for TabsToolbar padding based on approximate with of Windows caption buttons.

Currently I have no solution for Aero Basic. It seems the titlebar doesn't behave the same way.
Attachment #470622 - Attachment is obsolete: true
Attachment #471805 - Flags: feedback?(dao)
Comment on attachment 471805 [details] [diff] [review]
Tabs in titlebar when maximized v3

>+  #main-window[sizemode="maximized"][tabsontop="true"]:not([inFullscreen]):not([inTabView="true"]) #titlebar { 
>+    position: fixed;
>+  }

What's the reason for including :not([inFullscreen]) here?

>+  #main-window[sizemode="maximized"][tabsontop="true"][chromemargin] #toolbar-menubar {

This will probably be more efficient:

#main-window[sizemode="maximized"][chromemargin] #navigator-toolbox[tabsontop="true"] > #toolbar-menubar[autohide="true"]

>+  #main-window[sizemode="maximized"][tabsontop="true"][chromemargin]:not([inFullscreen]) #toolbar-menubar[inactive="true"] ~ #TabsToolbar { 
>+    -moz-padding-start: 9em;
>+    -moz-padding-end: 9em;
>+    padding-top: 1em;
>+  }

The dependency on [inactive="true"] causes the tab bar to resize when temporarily showing the menu bar. This is pretty bad especially when the tab bar is overflowing.

It's still not clear to me where the 'em' values come from. The end padding isn't supposed to have anything to do with the font size, is it?
Attachment #471805 - Flags: feedback?(dao)
Component: Tabbed Browser → Theme
OS: All → Windows 7
QA Contact: tabbed.browser → theme
Summary: Add option for placing tabs into Title Bar when window is maximized → Put tabs in the title bar when the window is maximized
Is this bug dead?

This userstyle is working for me, even with aero basic. (It has one bug: Fx button is positioned low in pop-up windows)

http://userstyles.org/styles/36877

( i didn't write the code )
That something is working for somebody isn't sufficient for including it in stock Firefox. The latest patch still raises some questions.

Jim, can we assume a certain width for the Minimize/Restore/Close buttons with aero glass? (and basic?)
I tried with a fresh profile, so it's working not only for me, it's working for everyone. Anyway, i didnt show to include this, i just showed because it might help.
The userstyle doesn't work at all on non-Windows platforms, so that's probably worth considering.  Mac for example has some unique challenges in that the title bar is managed by the platform itself, so it's not possible to just trivially shift the tabs into that space.
Hello, 
this put the TabsToolbar in the TitleBar:

#main-window[sizemode="maximized"][tabsontop="true"][chromemargin]
#toolbar-menubar[inactive="true"] ~ #TabsToolbar { 
    -moz-padding-start: 110px !important;
    -moz-padding-end: 110px !important;   
}

this move the menubar when press alt to the riht of the Firefox button:

#main-window[sizemode="maximized"][tabsontop="true"][chromemargin]
#toolbar-menubar {
    -moz-padding-start: 112px !important;
    margin-top: -22px !important;
}

this resolve the problem with Minimize/Restore/Close buttons with aero basic:

#main-window[tabsontop="true"] #appmenu-button-container {  
    position: relative !important;
    z-index: 1;
}

#main-window[tabsontop="true"] #titlebar-buttonbox { 
    position: relative !important;
    z-index: 1;
}

#main-window[tabsontop="true"] #TabsToolbar { 
    position: relative !important;
}
(In reply to comment #111)
> The userstyle doesn't work at all on non-Windows platforms

This bug is for only Win7!

Valerio: Thanks for the comments.
This bug is at least for Aero Glass.
Nope. It should apply to Aero Basic, too. (if i read Dao's reviews correctly)
Or this is what you say with "at least"?

(sorry for double post...)
Yep. It would be great if it could cover all Win versions and their themes.
My solution works with aero glass and aero basic...
What about XP, 2000 and Classic theme?
I know that, just Dao is sceptic about that...
I have windows 7 but if I set the classic theme it works...
someone with xp should try?
This bug is marked Windows 7. We should file seperate bugs for other OS.
The problem is Bugzilla doesn't have option for setting Windows All, so I left it as it was. But I filled this bug for all Windows, not only 7. If the implementation will require different approach in rest Windows, I shall fill additional bug.
Felipe: any way you can help with this? You've shown proficency with this type of thing in the past!
(In reply to comment #109)
> That something is working for somebody isn't sufficient for including it in
> stock Firefox. The latest patch still raises some questions.
> 
> Jim, can we assume a certain width for the Minimize/Restore/Close buttons with
> aero glass? (and basic?)

It would be relatively safe to set that in css. Although I don't believe we have the ability to differentiate between aero basic and xp themes yet. (bug 543910?)
How should Tab Candy look when the window is maximized? That's the issue I'm currently stuck on.
Why not same as now?
(In reply to comment #122)
> someone with xp should try?

I tried on XP. It's broken. The tabs are moved to right correctly, but didnt put into title bar.

Idk Joshua has a solution.
(In reply to comment #126)
> It would be relatively safe to set that in css. Although I don't believe we
> have the ability to differentiate between aero basic and xp themes yet.

Thanks. The theme can easily target aero basic.
Assignee: soapyhamhocks → dao
(In reply to comment #130)
> (In reply to comment #126)
> > It would be relatively safe to set that in css. Although I don't believe we
> > have the ability to differentiate between aero basic and xp themes yet.
> 
> Thanks. The theme can easily target aero basic.

How would we do that? Just curious.
In browser-aero.css using windows-default-theme and !windows-compositor.
To get the correct width for the close/min/max buttons Jim already implemented the necessary calls to retrieve the system metrics. I don't know if that's already exposed to CSS or not but it's likely straightforward.

Alternatively, instead of doing:

@media all and (-moz-windows-compositor) {
  /* these should be hidden w/glass enabled. windows draws it's own buttons. */
  #titlebar-buttonbox {
    display: none;
  }

we could make -moz-window-button-box render an empty element while in Aero mode, but with the correct dimensions. This would have the benefit that the CSS patch needed would have the same behavior for -moz-window-compositor or not (e.g aero basic).
> we could make -moz-window-button-box render an empty element while in Aero
> mode, but with the correct dimensions. This would have the benefit that the CSS
> patch needed would have the same behavior for -moz-window-compositor or not
> (e.g aero basic).

In fact, this already happens. Simply removing the display:none from #titlebar-buttonbox makes it take the correct space for the caption buttons.
(not sure if this will help, depends on the positioning strategy..)
(In reply to comment #135)
> > we could make -moz-window-button-box render an empty element while in Aero
> > mode, but with the correct dimensions. This would have the benefit that the CSS
> > patch needed would have the same behavior for -moz-window-compositor or not
> > (e.g aero basic).
> 
> In fact, this already happens. Simply removing the display:none from
> #titlebar-buttonbox makes it take the correct space for the caption buttons.
> (not sure if this will help, depends on the positioning strategy..)

That's probably the buttons or the titlebar, not the box. The box currently supports proper top/right padding, but it doesn't support dimensions.

http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsNativeThemeWin.cpp#1839

It should be easy to add dims though if we need it.
true, it's the buttons, not the box, but adding dimensions for it won't be even necessary! As the buttons themselves do support the proper dimensions, the container box is already sized properly.
(In reply to comment #137)
> true, it's the buttons, not the box, but adding dimensions for it won't be even
> necessary! As the buttons themselves do support the proper dimensions, the
> container box is already sized properly.

Be sure to check those dims are for aero glass and not aero basic. I'm not sure what that titlebar metrics query is getting.
I tried your patch on Win7 (both aero and aero basic), Joshua.

1. The tabs are too close to the Fx button. -moz-padding-start: 9.5em would be ok.

2. You dont take into account this. http://tinyurl.com/34hyf9d

3. Popup windows suck with this patch. The location bar is in the Title bar, too on them. :S And Fx button positioned 7x lower from window edge. I tried to play with [chromehidden=""] but i didnt suceed.

BTW, i have a totally other patch witch solves the third problem, but not properly the second. I already posted here.

Please, if you have a newer patch, share it. I'm sure you're working on it.
(In reply to comment #139)
> I tried your patch on Win7 (both aero and aero basic), Joshua.
> 
> 1. The tabs are too close to the Fx button. -moz-padding-start: 9.5em would be
> ok.
> 
> 2. You dont take into account this. http://tinyurl.com/34hyf9d
> 
> 3. Popup windows suck with this patch. The location bar is in the Title bar,
> too on them. :S And Fx button positioned 7x lower from window edge. I tried to
> play with [chromehidden=""] but i didnt suceed.
> 
> BTW, i have a totally other patch witch solves the third problem, but not
> properly the second. I already posted here.
> 
> Please, if you have a newer patch, share it. I'm sure you're working on it.

I was asked to leave some space on top to support Aero Snap. It seems Dão has taken over this bug. My understanding is it also requires some edits sNativeThemeWin.cpp which I don't have the skills to do.

I can come up with another patch unless Dão wants to work on it.
Faaborg/UX team asked this? Because two main goals of tabs in title bar are:

1. Save web content space
2. can easily click on tabs with with the usage of screen edge

I think supporting the second point is much more important than supporting Aero Snap. Most of the people don't use Snap, just the "Previous size" caption button.

What about the 1. and 3. point in my previous post?
(In reply to comment #141)
> Faaborg/UX team asked this? Because two main goals of tabs in title bar are:
> 
> 1. Save web content space
> 2. can easily click on tabs with with the usage of screen edge
> 
> I think supporting the second point is much more important than supporting Aero
> Snap. Most of the people don't use Snap, just the "Previous size" caption
> button.
> 
> What about the 1. and 3. point in my previous post?

I'll fix the spacing and popup windows and get a patch out today.
Ok, thanks.

The screen edge issue is decided?
Joshua, have you succeed with the fix?

Alex: Could you tell me what is the standpoint about Comment 139 #2 ?
>Alex: Could you tell me what is the standpoint about Comment 139 #2 ?

It is of course very important that the tabs can be activated when pushing the mouse to the screen edge.  If for some reason we have to address that in a follow up bug, I guess that's ok, but it's a pretty critical part of the reason we want to place tabs at the screen edge.

(On windows 7) If the user clicks and drags, I believe we should override the tab tear off action and instead use Aero Snap to restore the window down.
Thanks for the info, Alex!

On Windows 7: Wont it confuse the users? If window is unmaximized, tab tear off makes a new window. If window is maximized, tab tear off wont work, but uses aero snap by the same mouse action as tab tear-off on unmaximized window.
May I re-suggest that we instead leave a ~30px draggable area to the right of the tabs. That way we can both have the cake (draggable tabs) and eat it (draggable window/snap).
This may sound outrageous and overtly techie. But how about the tabs touch the window edge. However if you hover over the tab for X seconds it shrinks in height and allows the user use Aero snap. That way you have the best of both worlds.
Attached image Chrome leaves space right of tabs (obsolete) —
I just noticed, that's the way Chrome does it too.

It is logical (no change in behaviour) and simple to implement (just increase the space on the right of the tab bar).
(In reply to comment #148)
> But how about the tabs touch the window edge. 

Screen edge touching tabs look not as good as tabs with padding.

(In reply to comment #147)
> May I re-suggest that we instead leave a ~30px draggable area to the right of
> the tabs. That way we can both have the cake (draggable tabs) and eat it
> (draggable window/snap).

That 30px is not too much area, average user wont notice it ever. Making this area bigger looks ugly IMO.

Screenshot with 30px.  http://img829.imageshack.us/img829/53/30pxforsnap.png
The 30px idea doesn't really make sense to me. It's that close to the restore button that it's practically pointless.

While the shifting tab idea is more work for the devs, it's global to the top of the screen, it's innovative and user friendly/intuitive.
> (In reply to comment #147)
> > May I re-suggest that we instead leave a ~30px draggable area to the right of
> > the tabs. That way we can both have the cake (draggable tabs) and eat it
> > (draggable window/snap).
> 
> That 30px is not too much area, average user wont notice it ever. Making this
> area bigger looks ugly IMO.
> 
> Screenshot with 30px.  http://img829.imageshack.us/img829/53/30pxforsnap.png

Chrome uses an even smaller area, and they generally seem to know what they're doing in this area (UI). It is the logical place for people to look and drag. No need to learn new behaviour.

It would be interesting to hear what the UI experts think on this subject. Would save us a lot of guess-work here.
Attached image Mockup of dropping tab idea (obsolete) —
I definitely dont like either idea, David is correct, we should wait for Alex's comments.
Could we not land this and deal with the usability issue in a follow-up bug?
I think landing this is a really be a good idea - once this lands, we will have more people working with this feature in real-life scenario in Beta 7 and can give us better feedback on usability issues.
I think landing this is a really good idea - once this lands, we will have more people working with this feature in real-life scenario in Beta 7 and can give us better feedback on usability issues.
I'd say that we should try to get this in as soon as possible for feedback, getting the clicks to activate on screen edges should be OK to handle in the polish phase (post beta7).

I asked shorlander if he could apply the patch and report back on how the current implementation feels like, he'll add feedback here soon.
Comment on attachment 471805 [details] [diff] [review]
Tabs in titlebar when maximized v3

This patch is obsolete.
Attachment #471805 - Attachment is obsolete: true
Comment on attachment 478233 [details]
Mockup of dropping tab idea

This would cause too much movement and jittery behavior, and isn't the direction we'd like to go, I believe. Thanks for the suggestion, though. :)
Attachment #478233 - Attachment is obsolete: true
Comment on attachment 478227 [details]
Chrome leaves space right of tabs

Alex' mockup is still the direction for this bug, as far as I can tell. Brainstorming about other things should really move to the newsgroups.
Attachment #478227 - Attachment is obsolete: true
Attachment #471272 - Attachment is obsolete: true
Attachment #456201 - Attachment is obsolete: true
No longer depends on: 513159, 583959, 592210
No longer blocks: 581899
Feedback from shorlander:

> it doesn't work at all without glass
> with glass, it looks good but there are some spacing issues, not sure if that is because it is obsolete or not
We really don't need further feedback on that patch. It's not ready. The padding attempting to make room for the window controls is wrong. The padding attempting to make room for the app button is wonky in that it assumes the label to be "Minefield".
(In reply to comment #163)
> Feedback from shorlander:
> 
> > it doesn't work at all without glass

What do you mean? 
http://tinyurl.com/38m36nx
(In reply to comment #161)
> Comment on attachment 478227 [details]
> Chrome leaves space right of tabs
> 
> Alex' mockup is still the direction for this bug, as far as I can tell.
> Brainstorming about other things should really move to the newsgroups.

Well, I hadn't seen a mockup that deals with the situation of a full tab bar. Sorry, thought my comment was relevant here.
@Dao

So are you working on a new patch?
Any aproximate date to see this bug fixed on Minefield?
Attached patch Tabs in titlebar (obsolete) — Splinter Review
I started writing this patch and wasn't sure if it would lead to anything, but it seems to working quite well at the point that it is.

To get the correct size of the app button and close buttons, we get the size of the elements and write the CSS rules needed. Writing the rules instead of setting the styles directly means the JS don't have to watch for the changing conditions of tabs-on-top, maximized screen and visible menubar

It's all tied to a tabsInTitlebar attribute on the root element that can be used to turn it on/off easily.

Asking feedback (or review if the approach is sound) from Dao or Gavin.


This only applies to Win7 Aero glass for now. It's easy to extend that for other themes, but I'm not doing that at the moment as other themes will need polish on the background colors before turning it on.
Attachment #480249 - Flags: feedback?(gavin.sharp)
Attachment #480249 - Flags: feedback?(dao)
It still doesnt take into account this: http://tinyurl.com/34hyf9d
If that's really wanted that can be done as a follow-up later (or I can add to the main patch).

I didn't include it yet because there's an open question with that though: if someone is using a non-standard (bigger) caption buttons size, should the tabs just disconnect from the top, or stretch until they reach the top?

Current screenshot: http://grab.by/6EWb

It's not possible to override the dragging behavior and trigger Aero Snap
Alex, what's your thoughts on this?

Felipe: Does this work with popup windows?
Comment on attachment 480249 [details] [diff] [review]
Tabs in titlebar

Hmm actually, this has a bad effect on twinopen, so this patch is useless for now. I'll try some modifications to it to see if I can get rid of that, but I guess that's unlikely to happen with this approach.


> Felipe: Does this work with popup windows?
Csaba, is there any kind of popup window that displays the app button?
Attachment #480249 - Attachment is obsolete: true
Attachment #480249 - Flags: feedback?(gavin.sharp)
Attachment #480249 - Flags: feedback?(dao)
>if someone is using a non-standard (bigger) caption buttons size, should the tabs
>just disconnect from the top, or stretch until they reach the top?

Can we extend the hit area to the screen edge, but keep the current visual height of the tabs?

>It's not possible to override the dragging behavior and trigger Aero Snap

Is there anything that we can do in a follow up bug to try to make this possible?
(In reply to comment #175)
>
> Can we extend the hit area to the screen edge, but keep the current visual
> height of the tabs?

I always wanted to ask this. It does not just help this case, but it looks much better then screen-edge touching tabs.
Attached patch Patch v2 (obsolete) — Splinter Review
An update: the previous approach was prohibitive, because calling stylesheet.insertRule added about 15% to 20% of overhead to twinopen, depending on the rules being added.


So I went with a cleaner approach, which just adds two <spacer>s to the beginning and ending of the TabsToolbar. Their sizes are set by JS that retrieves the correct size of the appmenu-button and the caption buttons, and they switch between display:none and display:-moz-box with CSS tied to sizemode=maximized. This makes it possible to write all CSS rules directly.
However, oddly this still adds about 3-6% to twinopen, even if I remove the JS code on startup, so it seems that just the browser.xul and CSS changes do that. I have no immediate ideas on how to further reduce that.

Posting the patch if someone wants to experiment with it.

(In reply to comment #175)
> >if someone is using a non-standard (bigger) caption buttons size, should the tabs
> >just disconnect from the top, or stretch until they reach the top?
> 
> Can we extend the hit area to the screen edge, but keep the current visual
> height of the tabs?

It's likely possible with some padding and shadow changes to the tabs, but I haven't looked into details of how its appearance (including the border shadow) is implemented

> 
> >It's not possible to override the dragging behavior and trigger Aero Snap
> 
> Is there anything that we can do in a follow up bug to try to make this
> possible?
I need to think of all the widget-side implications to do that, but I believe so, yeah. This would require some scary changes around the drag-n-drop code, so a follow up bug to investigate it's feasibility for the future would be the way to go.
Any news on this bug, now that the trunk is fully open again?

Being a 7 year old user of firefox, from the time when it was called Firebird, I truly believe this is very important from a user perspective. 
If this doesn't get shipped with 4.0, I'll have to use an extension on every single machine with Firefox I use, to have this feature, it's a must have...
Why is this bug taking so much time?
(In reply to comment #179)
(In reply to comment #180)

Evangelism isn't welcome in bugs. Please stop, or else I'll be forced to rescind your Bugzilla accounts.
BTW, can i request blocking BetaN+, Mike?

To Felipe, or Dao, or anyone who's working on this:

Comment 173 - Comment 174 is still here.
Beta7, the feature freeze is just around the corner, and this bug is totally abandoned, but wanted by the UX team. Is there any news on this?
Yeah, the gigantic whitespace beside the Firefox button does just come
off as a "waste" when seen for the first time, especially when
compared to Chrome (and in particular when Vista/7 Aero is on,
creating a huge transparent space). Wasn't the intent all along to create the space beside the single Firefox button in-able to move the tabs up beside it, thus giving more vertical viewspace? If that was never the intent, what was the purpose of removing the display of the current page title? Why remove yet more info just to replace it with whitespace? Does anyone at least know of a
stylish theme that can implement this in the meantime?
(In reply to comment #184)

You can try:

http://userstyles.org/styles/38837 Firefox 4 tabs in titlebar & FF logo menu button

or

http://userstyles.org/styles/32627 Slimmer Firefox 4.0

or

https://addons.mozilla.org/en-US/firefox/addon/13505/ Hide Caption Titlebar Plus (Smart)
(In reply to comment #177)
> Created attachment 480825 [details] [diff] [review]
> Patch v2

> 
> Posting the patch if someone wants to experiment with it.

Now that bug 608717 has landed, the MENUBAR_CAN_AUTOHIDE ifdefs in this patch should probably all be changed to CAN_DRAW_IN_TITLEBAR.
With a few tweaks of one of the userstyles, I've got this working perfectly (at least from what I can perceive). The question however remains in regards to comment #164:
> The padding attempting to make room for the app button is wonky in that
> it assumes the label to be "Minefield".
Is there a way to get the length in XUL? In HTML, you'd use JS to get clientWidth and go from there.

If we can get that bit sorted out, surely it's just a matter of adding the conditional wherever need be to ensure that it only appears on systems that support drawing in the title bar.
I'm renominating this to block Firefox 4.  The efficiency gain of leveraging the screen edge was one of the primary reasons we placed tabs on top.  This issue is coming up on feedback a lot, and we've also seen the tech press draw the conclusion that we will be likely fixing this before we ship.
blocking2.0: - → ?
Don't forget that Fitt's law doesn't work when we have bars above maximized windows. Like in Ubuntu, with the toolbar at the top edge of the screen. Or like in Windows, if the user has the taskbar on the top edge, instead of the bottom edge.
Depends on: 569850, 611827
Attached patch patch (obsolete) — Splinter Review
This has issues getting the correct title bar metrics in TabsInTitlebar._update when opening maximized windows on Win7 (aero glass, basic as well as classic). Apparently it gets the numbers for sizemode=normal even though the window is maximized. When restoring the window and maximizing it again, the numbers are correct.

This isn't a problem on XP.

Felipe or Jim, any idea what's going on?
Attachment #480825 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
Found a workaround. I guess this is ready then.

This implements tabs in the title bar for all flavors of Windows. It also adds a browser.tabs.drawInTitlebar hidden pref for users to opt out or (in case we disable it by default for whatever reason) opt in.
Attachment #490557 - Attachment is obsolete: true
Attachment #490586 - Flags: feedback?(felipc)
Blocks: 610561
Tested on XP:
1. Title bar is plain blue.
2. FXB is smaller in both width and height.
3. Caption buttons are touching nav bar.
4. Buttons placed in title bar have wrong hover effect.
There is some extra space on both ends of the tab strip.[Win7]
Perhaps this is another bug, but shouldn't the Panorama Button stay up in the title-bar if this is enabled, instead of popping below the min/max/close buttons when you go into it? Sorta odd to have the two different placements now.
I don't see any real issues.  Looks great.  Here are the minor things I noticed:

1) Spacing seems a little wide on the right?  It might be intended but I put up a screenshot
2) The Firefox button does appear smaller but it doesn't look bad to me and I didn't comapre it.
Looks great, another small glitch: tab overflow button on the left is placed between app tabs and the rest of the normal tabs
Great work, Dão!

Two issues:

- there are two much space on the left between FXB and the first tab

- if I put a button to the tab-bar, the new tab button moves to the very right, fixed.
Comment on attachment 490586 [details] [diff] [review]
patch

I like the approach, specially what you did to calculate the vertical shift.

Some comments:
 - is there any reason to dynamically create the spacers, instead of having them there and just show/hide them? (Is it due to the list toolbarIDs that may grow in the future? just curious for the reason)
 - You could get rid of the disallowedCount by using Object.keys(obj).length
 - does the pref observer need to be removed when the window closes?

The only thing that I didn't like is having a fixed width for the appmenu-button.
I think that add-ons might want to change the content for that button and this will make it harder for them to do so. I'd instead calculate the width of that button and size the left side with spacers too. (And separate sizing and updating into 2 functions and make the sizing one public)

(I believe the shrunk appearance is intentional, right? kind of halfway to bug 610561.. but personally I like the wider appearance better)


Did you get talos numbers and got any idea on what was being affected by the previous patch here? FWIW I think that the patches that Jim landed this weekend (bug 611693) also got rid of the txul regression that would show on my previous patch.
Attachment #490586 - Flags: feedback?(felipc) → feedback+
Menubar(Alt+F) is not visible completely.
The firefox button changes size too often, for instance during panorama view, customize view, restored window. The size needs to be fixed.
(In reply to comment #196)
> 1) Spacing seems a little wide on the right?  It might be intended but I put up
> a screenshot
This is for Windows 7 drag/snap.  Probably don't need space on both sides though.. maybe remove the space on the left.
(In reply to comment #202)
> (In reply to comment #196)
> > 1) Spacing seems a little wide on the right?  It might be intended but I put up
> > a screenshot
> This is for Windows 7 drag/snap.  Probably don't need space on both sides
> though.. maybe remove the space on the left.

Why are you adding space for Windows 7 drag/snap when the UX team made it clear on here that dragging anywhere in the title bar (including on the tabs) would still drag/snap the window?
(In reply to comment #203)
> Why are you adding space for Windows 7 drag/snap when the UX team made it clear
> on here that dragging anywhere in the title bar (including on the tabs) would
> still drag/snap the window?

Because the current patch doesn't have space above the tabs, due to the Fitz Law argument. The space is there so you can drag the window still if the entire bar is filled with tabs.
(In reply to comment #204)
> (In reply to comment #203)
> > Why are you adding space for Windows 7 drag/snap when the UX team made it clear
> > on here that dragging anywhere in the title bar (including on the tabs) would
> > still drag/snap the window?
> 
> Because the current patch doesn't have space above the tabs, due to the Fitz
> Law argument. The space is there so you can drag the window still if the entire
> bar is filled with tabs.

You mis-understand my post. I know what the current patch does - it shifts the tabs up into the title bar. However, Faaborg and Limi pointed out that it was intended that dragging anywhere in the new compact tabbed-titlebar (including on the tabs) will still drag the window (comment #98, comment #99, comment #145).
I tried out the try server build.  Overall it looked good, the only immediate thing I noticed was that drag operations with windows 7 in the maximized state weren't trigger an Aero Snap tear off, but were instead being used for tab tear off.  We would like to default to using Snap for drag operations, even directly on tabs.  The assumption is that the user is less likely to tear tabs off when the window is maximized, and trying to support both simultaneously is too confusing.
Has anyone else mentioned the issue someone raised on mozillazine yet with the test build? They said that the location arrows that appear when you drag the tabs to rearrange them are no longer appearing (too high off the screen maybe)?
That will be fixed by bug 455694.
(In reply to comment #206)
> We would like to default to using Snap for drag operations, even directly
> on tabs.  The assumption is that the user is less likely to tear tabs off when
> the window is maximized, and trying to support both simultaneously is too
> confusing.

How will you differentiate between an aero snap tear and a dragging a tab to change its position?  Because, it's probably true that snap is more used than tearing off a tab.  But I'm not as sure about changing a tab's location.
We'll need a threshold for horizontal movement to still allow for tab re-arrangement.  If we start to do real time tab drag animations for reordering, then we'll start the movement immediately, and cancel it once the mouse moves down a certain distance vertically (similar to how we currently handle move versus tear).
(In reply to comment #210)
> We'll need a threshold for horizontal movement to still allow for tab
> re-arrangement.  If we start to do real time tab drag animations for
> reordering, then we'll start the movement immediately, and cancel it once the
> mouse moves down a certain distance vertically (similar to how we currently
> handle move versus tear).

Alex - that is a great idea - I love it!

An other idea that I was going to suggest could be to do something like on the iPhone. e.g. long-click on a tab (or right-click and select "Unlock tabs" -  cf Windows Taskbar), then the tabs start wobbling and allow you to tear them off or rearrange them.
(In reply to comment #206)
> I tried out the try server build.  Overall it looked good, the only immediate
> thing I noticed was that drag operations with windows 7 in the maximized state
> weren't trigger an Aero Snap tear off, but were instead being used for tab tear
> off.  We would like to default to using Snap for drag operations, even directly
> on tabs.  The assumption is that the user is less likely to tear tabs off when
> the window is maximized, and trying to support both simultaneously is too
> confusing.

Felipe signed up for this as a follow-up in comment 178. :) It sounds scary, though, and I wouldn't count on it being ready for Firefox 4.

(In reply to comment #199)
>  - is there any reason to dynamically create the spacers, instead of having
> them there and just show/hide them? (Is it due to the list toolbarIDs that may
> grow in the future? just curious for the reason)

I didn't want to set -moz-ordinal-group on every toolbar child, but I found a way around that (thanks to the ordinal attribute being less restricted than the CSS property).
Attached patch patch v2 (obsolete) — Splinter Review
Attachment #490586 - Attachment is obsolete: true
>Felipe signed up for this as a follow-up in comment 178. :) It sounds scary,
>though, and I wouldn't count on it being ready for Firefox 4.

Sorry about that, missed the earlier comment.  Instead of overriding the drag and drop code, for the time being is there any chance that we could insert a few pixels so that drag operations on the screen edge would act on the title bar, and also still handle down click/upclick operations to allow the user to switch between tabs?
Just for the record. As a user, who has been user a userstyle to achieve this bug for an extended period of time. I'm far more interested in dragging tabs to create new windows than I am to play with restore windowed mode. But can we make a right click option appears (in order to move the tab to a new window).

Though for the record, I'm against this change to drag/drop behaviour where it's one method for windowed mode and another for maximised. It's confusing.
(In reply to comment #214)
> >Felipe signed up for this as a follow-up in comment 178. :) It sounds scary,
> >though, and I wouldn't count on it being ready for Firefox 4.
> 
> Sorry about that, missed the earlier comment.  Instead of overriding the drag
> and drop code, for the time being is there any chance that we could insert a
> few pixels so that drag operations on the screen edge would act on the title
> bar, and also still handle down click/upclick operations to allow the user to
> switch between tabs?

I can have a look. In the meantime I think we can move forward with the current implementation, even if disabled by default through the hidden pref.
With the second trybuild and with firefox in maximized mode, If I go to print preview and then I close it, the tab bar doesn' t come back on the titlebar
No longer depends on: 611827
Attached patch patch v3 (obsolete) — Splinter Review
fixed the print preview bug
Attachment #490827 - Attachment is obsolete: true
Attachment #490872 - Flags: ui-review?(faaborg)
Attachment #490827 - Flags: ui-review?(faaborg)
Should bug 455694 be set to block this then? Without that implemented, there is no way to get an indication of where your tab will go when reordering (on XP theme).
(In reply to comment #220)
> Should bug 455694 be set to block this then?

No, we could just move the drop indicator down so that it's visible.
I think the best way is to make all toolbars moveable (up/down), remove "Tabs on top" option. In addition to 4 standart toolbars (Menu bar, Navigation toolbar, Bookmarks toolbar, Addon bar) add another one - "Tabs bar".
And make title bar customizable as other toolbars (we have bug for this).
So user will be able to move that toolbars as he want and browser interface will be FULLY customizable.

For the matter of this bug - in fullscreen mode we can hide "future" Tabs bar and move all its content to title bar.

Any other ideas how to make it better?
Why not just add a pref ? 

For eg : http://img88.imageshack.us/img88/1232/34205427.png
Should Bug 574859 be considered while fixing this bug?
(In reply to comment #225)
> Should Bug 574859 be considered while fixing this bug?

Right clicking on the glass to produce the system menu should still work fine.
Right clicking the title bar does not bring up the system menu on Windows xp with tabs in the title bar.
Dao: Comment 198 is still here.
Overall it works perfect for me, but I found one little bug.. If you click outside the window, the button stays orange but it should be transparent (like min/max/close buttons) as in beta 7.
(In reply to comment #229)
> Overall it works perfect for me, but I found one little bug.. If you click
> outside the window, the button stays orange but it should be transparent (like
> min/max/close buttons) as in beta 7.

Not a bug, that's the new intended behavior post beta 7.
(In reply to comment #198)
> - if I put a button to the tab-bar, the new tab button moves to the very right,
> fixed.

If you put something between the "new tab" button and the tab strip, the "new tab" button won't merge with the tab strip. May patch doesn't change this.
Despite being labelled as [parity-opera], this patch is still really failing on the usability front by comparison. The main problems are:

1. The gap above the tabs doesn't allow you to grab the window bar
2. There's no compensating space around the tabs to grab instead
3. There's no pref to turn this off (despite sarcastic comment #10 -- what happened to it?)

These give rise to:
1. It really blows for multiple screens -- moving a window between screens goes from a single drag (with Fitts' benefits) to a series of aimed clicks and careful mouse movements (move, click, move, drag, move, click)
2. We lose the the system menu (bearing in mind the Firefox button removes the normal click location for it)
3. We lose the ability to double-click to restore a window (again, a much larger hit target)

Oh, and we also lose the page title. (Why? Is that a good trade-off for anything except a net-book?)



In slightly more detail:

Opera leaves a slightly bigger gap above the tabs, but more importantly, it lets you use snap across the full width of the screen. Try it -- it works really well. The thin size doesn't matter because Fitts' law is working for us -- it's effectively infinite height. I can still easily select tabs -- they have a large hit area, and we benefit from the "bounce" off the top of the screen.

The Firefox design trade-off, giving this privilege to the tab, works less well. We tend to trigger tab tear-off where we didn't before, and we lose access to the standard window controls. On my setup (I didn't change anything from my normal configuration to take this screen shot - http://img715.imageshack.us/img715/9057/toolbarb.png), I measured about 15 px width that would allow snap. That's less than 0.8% of my main screen. Trust me - it's really hard to hit.


In summary, I think the look is acceptable, but the behavior would be a lot better if we copied the Opera behavior. At least try a Windows 7 multi-monitor setup before deciding to commit this patch. Please?
(In reply to comment #232)
IMO, tabs in title bar should be an option. Then ...

The users want to drag the window or use the system menu can disable it to have a nice title bar.

The users like me do not drag the window so much (I saw many people just keep the browser window maximized), and want more vertical space plus Fitts' benefits on the TABS would prefer the current arrangement. I think Opera's approach just waste too much space make put tabs on title bar meaningless.
Its parity chrome first , and chrome implements it in the same way and i dont find any good reason to have space in between for Aero Snap , it wastes space , and Fitts' law is not held properly. 

Current implementation is perfect i guess :)
A quick note regarding using the tabs for Aero Snap. Both Opera and Chrome both ignore Aero Snap over tearing off tabs to create new windows. Perhaps we should create a hidden pref to switch to the behaviour of Aero Snapping when you tear tabs?
(In reply to comment #232)
> The Firefox design trade-off, giving this privilege to the tab

It might be your personal opinion that it's a trade-off but judging from the comments here I guess there are quite some individuals (including me) who don't share your opinion and Opera's opinion. Also, if you will look into Opera's forums you will see that not all agree with Opera's way of handling this and in the theme directory you will find quite some skins specifically removing this gap.

TBH, I can't understand how someone would prefer to have quicker access to the window than to the tab functions when in maximized mode. Also, there's always the option of accessing the menu through the taskbar entry.
Screenshot: http://min.us/mveULMQ
Tab scroll button are visible without any tabs open for overflow, using the build for patch v3. Is it anyhow related?
The way I have it set up, I have a 1 pixel gap at the top to allow for aero-snap.  This takes up a negligible amount of space and it's still very easy to select a tab by bouncing off the top of the screen.  This works perfectly for me, but I could see how others wouldn't want the gap.  As for overriding tab tearing for aero-snap, I think this would be a really bad idea as it creates inconsistencies in the interface.
Just passing by with some idea of mine...

What about making the Firefox button draggable for Aero Snap?
The way I see it, the space is taken up anyway, so why not make the most of it?
(In reply to comment #239)
> Just passing by with some idea of mine...
> 
> What about making the Firefox button draggable for Aero Snap?
> The way I see it, the space is taken up anyway, so why not make the most of it?

Wow, don't know if that's doable, but I really do like the idea. Firefox Button is already now a main target. It's large and really stands out due to the color. Seems much more logical target than a small space between it and the tabs.
I created an account just to share my opinion. I always find usability discussions interesting. :-)

Anyways, my money is on making the Firefox button draggable for Aero Snap just as comment #239 said. I can live without Aero Snap for window, I am more concerned about accessing my tabs as quick as possible. So I guess it should be implemented somewhere else and Firefox button, for me, is the most strategic place.

Please don't place a gap above the tab bar, it's a terrible idea.
That's an interesting idea. The problem is that there's no precedent for it in any other software, and good UI design is about taking advantage of things which users are already used to.
(In reply to comment #242)
> That's an interesting idea. The problem is that there's no precedent for it in
> any other software, and good UI design is about taking advantage of things
> which users are already used to.

The precedent in both Opera and Chrome is to largely ignore Aero Snap in maximised mode in favour of retaining tab behaviour.
(This has been said before, but obviously needs repeating.)

Chrome's solution is the most logical, simple, and intuitive. We should just do
what they do:

1. Tabs that go all the way up for easy targeting.
2. A small space, n pixels wide, between the right-most tab and the minimize/restore/close buttons which always is available for dragging the window and Aero snap.

(Obviously, in non-maximized state we can skip the space to the right and have
a border above the tabs instead.)
Another thing that Chrome does that is very nice is that the new tab button doesn't fill up the entire vertical space, so that adds some more available area for dragging.  I think that we should do the same with any buttons that are on the tab bar.
@comment #244. Perhaps place that "n pixels wide" between the left-most tab and Firefox button. Also make the latter draggable for Aero snap. That setup would lead users to accidentally drag it(miss the "n pixels wide") and discover what it does.
Comment on attachment 490872 [details] [diff] [review]
patch v3

overall this is great, one small nit: I think it would look better if we matched the padding on the bottom and right side of the Firefox button (I'll attach a mockup).
Attachment #490872 - Flags: ui-review?(faaborg) → ui-review+
Seems more balanced if we have less white space to the right of the Firefox button, and match the space we have below it (5px).
Depends on: 613859
Attached patch patch v4 (obsolete) — Splinter Review
Reduced the padding as per comment 248.
Attachment #490872 - Attachment is obsolete: true
Attachment #492320 - Flags: review?(gavin.sharp)
How are we going to handle the drag indicator when tabs are at the top of the screen?  Currently the arrow is placed above the tabs, but it won't be visible in this case.
(In reply to comment #250)
> How are we going to handle the drag indicator when tabs are at the top of the
> screen?  Currently the arrow is placed above the tabs, but it won't be visible
> in this case.

I would say flip the indicator upside down.
(In reply to comment #250)
> How are we going to handle the drag indicator when tabs are at the top of the
> screen?  Currently the arrow is placed above the tabs, but it won't be visible
> in this case.

Moving tabs dynamically when hovered with other tab grabbed (like windows 7 taskbar) would look great. Dont know if it can be implemented.
(In reply to comment #252)
> Moving tabs dynamically when hovered with other tab grabbed (like windows 7
> taskbar) would look great. Dont know if it can be implemented.

I definitely agree, which is how all of the other modern browsers handle it, but I think that's out of the scope of this bug.
(In reply to comment #252)
> Moving tabs dynamically when hovered with other tab grabbed (like windows 7
> taskbar) would look great. Dont know if it can be implemented.

I thought that's already happening? See bug 455694.

The bug's just inactive at the moment... 
But as soon as it's implemented, the indicators shouldn't even be needed anymore.
(In reply to comment #254)
> (In reply to comment #252)
> > Moving tabs dynamically when hovered with other tab grabbed (like windows 7
> > taskbar) would look great. Dont know if it can be implemented.
> 
> I thought that's already happening? See bug 455694.
> 
> The bug's just inactive at the moment... 
> But as soon as it's implemented, the indicators shouldn't even be needed
> anymore.

Right, the indicators should go away as soon as we have tab dragging animation, which is being worked on by Frank Yan. I'll ask him to comment here, but I suspect we don't need to worry about it, at least for now.
(In reply to comment #252, comment #253, and comment #254)

Yes, I'm working on it. Indicators (which are half-broken on Mac already) and awkward tab thumbnail drag images will go away, etc.
In the event that the tab animations aren't in-sync (ie - don't get included into trunk at the same time) with this patch, would it be possible as a temp fix for this patch to flip the arrow position indicator vertically for the time being (so that it's below the tab line instead of above as it is now)? Just wondering.
Attached patch patch v4 (obsolete) — Splinter Review
updated to tip
Attachment #492320 - Attachment is obsolete: true
Attachment #494667 - Flags: review?(gavin.sharp)
Attachment #492320 - Flags: review?(gavin.sharp)
is there a tryserver build for patch v4 ? I want to test latest change.
No longer depends on: 613859
(In reply to comment #259)
> is there a tryserver build for patch v4 ? I want to test latest change.

I don't know of a tryserver build, but this, as well as several other in progress UI changes, is included in my daily builds available at:

http://www.wg9s.com/mozilla/firefox/
(In reply to comment #260)
> (In reply to comment #259)
> > is there a tryserver build for patch v4 ? I want to test latest change.
> 
> I don't know of a tryserver build, but this, as well as several other in
> progress UI changes, is included in my daily builds available at:
> 
> http://www.wg9s.com/mozilla/firefox/

well, thank you so much, That's what i needed.
(In reply to comment #260)
> (In reply to comment #259)
> > is there a tryserver build for patch v4 ? I want to test latest change.
> 
> I don't know of a tryserver build, but this, as well as several other in
> progress UI changes, is included in my daily builds available at:
> 
> http://www.wg9s.com/mozilla/firefox/

Tabs are not in the title bar with this build on Windows Xp, dao's one worked...
The build sure works for me.  Are you sure you had the window maximized?  Tabs are only in the title bar on maximized windows.
Bill's build also works for me in maximised windows when the Menu bar is not ticked
Just tried again: build is ok with this bug https://bugzilla.mozilla.org/show_bug.cgi?id=589146, bug tabs are always in the same place...

http://img574.imageshack.us/i/firefoxpatch.png/
Blocking+ per comment #28 and #57, which clearly show this is "a user experience problem deemed significant by the user experience team".
blocking2.0: ? → final+
http://i55.tinypic.com/313rvqq.jpg

i use a non standard theme...
(In reply to comment #267)
> http://i55.tinypic.com/313rvqq.jpg

You appear to be using Bill's build without the patch for bug 569850.
(In reply to comment #265)
> Just tried again: build is ok with this bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=589146, bug tabs are always in the
> same place...
> 
> http://img574.imageshack.us/i/firefoxpatch.png/

Ok, I've changed theme and then changed again to standard luna, now it works...
(In reply to comment #268)
> (In reply to comment #267)
> > http://i55.tinypic.com/313rvqq.jpg
> 
> You appear to be using Bill's build without the patch for bug 569850.

I am now including that patch in my builds as well, so others will not run into this issue.
is there a reason why this patch didn't get review ?
double clicking maximizes the window rather than opening a new tab, which is what i expected.
(In reply to comment #272)
> double clicking maximizes the window rather than opening a new tab, which is
> what i expected.

Bug 575248
Ah, i wasn't sure that that was related to this. in that, they spoke of how there was an add tab button, which i didnt have, and i didnt think it was a bug on this one, but a bug on firefox itself as of august.
With this patch applied, under Windows/XP using the Luna theme, there is not enough contrast between the titlebar color and the List-all-Tabs and Panorama icons.
(In reply to comment #275)
> With this patch applied, under Windows/XP using the Luna theme, there is not
> enough contrast between the titlebar color and the List-all-Tabs and Panorama
> icons.

bug 580194
Whiteboard: [parity-chrome][parity-opera] → [parity-chrome][parity-opera][target-next-beta]
The group tabs button should be moved so it remains in the title bar when the group tabs button is clicked.
Whiteboard: [parity-chrome][parity-opera][target-next-beta] → [parity-chrome][parity-opera][target-next-beta][d?]
Attached patch patch v4 (obsolete) — Splinter Review
updated to tip
Attachment #494667 - Attachment is obsolete: true
Attachment #499502 - Flags: review?(gavin.sharp)
Attachment #494667 - Flags: review?(gavin.sharp)
Gosh, I feel so... unlearned. How would one go about applying one of the above mentioned patches?
Found Bill G's build after reading all the posts (as I should have before). The only thing I've found not working (that works with browser.tabs.drawInTitlebar toggled off) is middle mouse click in the TabsToolbar. 

I do miss glass with tabs-on-top though. ;)

http://www.flickr.com/photos/57257495@N04/5295394883/sizes/l/in/photostream/
Please do not post screenshots of a customized theme. It's confusing.

Middle click is working for me.
I posted some css , for use in xul, in bug 620303. i was however told that it was appropriate only for maximized views...
either opera or chrome's design would work, I just hope there will be enough beta cycles to test this. Its a relative big change, it will need more time to test by end users.

PS. I like Opera's design more, because eventually people may run out of horizontal space for windows operation, while reserve top 1-5px for aero operation will satisfy everybody.
(In reply to comment #285)
> either opera or chrome's design would work, I just hope there will be enough
> beta cycles to test this. Its a relative big change, it will need more time to
> test by end users.
> 
> PS. I like Opera's design more, because eventually people may run out of
> horizontal space for windows operation, while reserve top 1-5px for aero
> operation will satisfy everybody.

Opera's design wins you a few vertical pixels. Chrome's design wins you another bunch of vertical pixels AND totally changes how you use tabs. You begin to see tabs as programs in a taskbar. Leaving a few pixels at the top because you can't think of another way to grab the titlebar is a weak argument.
I hope Firefox will improve upon Chrome instead of the halfway tabs on top that Opera has.
I don't have chrome, so I can't arguing about what it does or doesn't do. My only concern with chrome style, as I guessed from other people's post, is when you open too many tabs and eventually run out of the horizontal space, then what?

Either way, the wg9s.com's build is no good IMHO. when maximized, double clicking the empty space on right side of the tab bar does one thing, when unmaximized, double clicking that same space does something else. Its way too inconsistent.
(In reply to comment #287)
> I don't have chrome, so I can't arguing about what it does or doesn't do. My
> only concern with chrome style, as I guessed from other people's post, is when
> you open too many tabs and eventually run out of the horizontal space, then
> what?
> 
> Either way, the wg9s.com's build is no good IMHO. when maximized, double
> clicking the empty space on right side of the tab bar does one thing, when
> unmaximized, double clicking that same space does something else. Its way too
> inconsistent.

Yes, you're right there should be consistency. But the UX team decided against it, no point in moaning here, go to their usergroup. Also, when you run out of horizontal space on the title bar (tab strip), the same thing that happens now will happens. i.e. tab overflow. It's a no-brainer.
what "same thing that happens now"? there are plenty of space between tabs and the windows upper border now, so there is no problem "NOW".
OK.  We get the point!

I have a few points to make though.

1.  Although I am providing builds here, I have had nothing to do with the development of this patch.  I think people are giving me more credit here than I deserve.

2.  All of this discussion is really not relevant in this bug.  This bug is about putting tabs in the title bar.  It was never about making the titlebar work the way the tabbar does now.  However, I do understand the confusion caused by having the mouse appear to work differently in maximized and non-maximized mode.

3.  There is already inconsistency about the way the mouse buttons work under vista/Windows 7.  With an aero theme, if you have tabs on top, double-click on the tabbar works identically to double-click in the titlebar.  With a non-aero theme a double-click in the tabbar opens a new tab.

To fix all of this and make it consistent, I would like to change it so that under windows, if you have tabs-on-top, the only mouseclick on the tabbar that will open a new tab is the middle click II never understood why we needed both double-click and middle click to perform the same function here in the first place).  Then I would also like to change it so that a middleclick on the titlebar opens a new tab if we have tabs-on-top.

I will be filing a new bug to do that and post the bug number back here.
I'm having trouble with the logic behind "when maximized". Isn't screen real estate at the highest premium when multiple windows are sharing it? (Specifically, stacked.)
I (personally) agree. but I'd like to hear the logic behind the decision.
The first reason is Fitt's law, in the maximized state you can use the screen edge to easily target the tabs: http://people.mozilla.com/~faaborg/files/20100625-tabsOnTop/mouseInfinity.png

Anyway, following this logic, tabs should be in the title bar when the user puts the window(s) on the half screen via dragging it to the left or right side of the screen!

http://img602.imageshack.us/img602/9504/tabsintitlebaraerosnaps.png
Unfortunately, Aero snap doesn't let you place a window in each quadrant of the screen - and as mentioned above, this seems like a usage case where vertical screen real estate would be the most valuable. But what's the reasoning behind not always doing it? Is the only reason that it makes dragging the window more difficult? It's not like the firefox button and system menu buttons take a lot of horizontal space away from the tabs, after all (I personally have it set up very differently, with the classic menu in the title bar and the window title next to it, so this isn't a request).
Chrome does not have tabs in title bar when un-maximized, too. I guess the UX decision was dragging the un-maximized window is more important than save space in most cases.
(In reply to comment #295)
> Is the only reason that it makes dragging the window more difficult?

This is probably not the only reason, but this is a reason, yes. Currently the area to drag the window is only ≈ 12 pixels high. Reducing this further would be very stupid. And even more if you consider touch screens and similar input methods which don't allow for easy pixel precise positioning of the cursor.

Additionally, it probably doesn't look good if you stuff everything to the top edge. It is okay when maximized because of Fitts's law and considering screen space on netbooks netbooks but if it is not maximized on a large screen, it will look stupid.
I like the ~30 px drag and click area adjacent to the minimize button idea. The css hack I was using used about that. It was plenty, and it's wider that the title is high I believe. (If the title bar is high enough for non-mouse click-drag, then that width should be wide enough.)

It's also intuitive. As tabs filled the title bar I was forced to use a smaller and smaller area to click-drag. As long as it doesn't disappear altogether (or seem to), I think most users will adapt naturally.

Ahh, aesthetics. As with art, I'm no critic but I know what I like. Problem is, so does everyone else. When it comes to browsers I prefer the style "form follows function". I actually find non-maximized tabs in title bar appealing though.

Considering that a double-click minimizes-maximizes a window, I say kill the restore button!
My humble request: Whatever the final solution is, please make sure that it's well indicated in the "What's new in this release", so that users don't have to dig in developer-intended documentation to find out about how this feature works. A nice short how-to video would be ideal. The problem with some features isn't the fact they're intuitive/non-intuitive. It's just that the user doesn't know about them at all.
This is a another stupid idea from Mozilla!  Please don't implement this.

Microsoft Office started screwing up the normal title bar with their 2007 release. Some other apps followed on, copying the MS Office UI change, which cause conflicts with other applications.

I use the titlebar to display the page title and website on the left side. On the right side I display the date and time using an old freeware app.

See:
http://i.min.us/ibGjxE.jpg

I also run another old freeware app that allows me to right-click on the title bar and make the window body invisible (just the title bar showing). I think that the app WindowBlinds does this also. These "roll-up apps don't work with the MS Office corrupted titlebar and now, looks like they won't work once Mozilla gets finished screwing up the FF title-bar.
Additionally, has any thought been given to how this patch or whatever it is called would affect people like myself that have 40-70 tabs open all the time?
You're welcome to stay on 3.6 if you want. 
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
If you actually bothered to look at the patch, you would have noticed it adds a preference pref("browser.tabs.drawInTitlebar", true); You can just set this to false in about:config.
(In reply to comment #301)
> Additionally, has any thought been given to how this patch or whatever it is
> called would affect people like myself that have 40-70 tabs open all the time?

In any case , you would just lose space as much as the size of firefox menu button and caption buttons , which might be reduced even further if firefox menu button is shrinked , seeing the benefit of the feature , this so-called disadvantage seems negligible , its good to access tabs easily first than to access 40 tabs easily first , and in any case , you can disable it from pref as mentioned above :)
Using Bill's build in Windows 7, it seems like Fitts's law doesn't apply to the whole New Tab button.
http://oi56.tinypic.com/vse39t.jpg
(In reply to comment #305)
> Using Bill's build in Windows 7, it seems like Fitts's law doesn't apply to the
> whole New Tab button.
> http://oi56.tinypic.com/vse39t.jpg

It seems that under windows 7 with Aero, the new tab button only seems to work at its top edge on the right hand side of the button.  On the left hand portion it is not clickable.
Comment on attachment 499502 [details] [diff] [review]
patch v4

>diff --git a/browser/base/content/browser.css b/browser/base/content/browser.css

>+#titlebar-spacer,
>+#main-window[tabsintitlebar]:not([inFullscreen]) .tabbrowser-arrowscrollbox > scrollbox > .scrollbox-innerbox {
>+  pointer-events: none;
>+}
>+
>+.tabbrowser-tab,
>+.tabs-newtab-button {
>+  pointer-events: auto;
>+}

Why is this needed?

>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js

>   _toggleAffectedChrome: function () {

Why this change?

>+  _update: function () {

>+    let docElement = document.documentElement;

nit: move this to above where it's first used

>+    let allowed = true;
>+    for (let something in this._disallowed) {
>+      allowed = false;
>+      break;
>+    }

let allowed = Object.keys(this._disallowed).length > 0; // ?

>+  uninit: function () {

>+    this._initialized = false;

Why is this flag needed?

>diff --git a/browser/themes/winstripe/browser/browser.css b/browser/themes/winstripe/browser/browser.css

>+%ifdef WINSTRIPE_AERO
>+@media not all and (-moz-windows-compositor) {
>+%endif
>+  #main-window[tabsintitlebar] #titlebar-content:not(:-moz-lwtheme),
>+  #main-window[tabsintitlebar]:not([inFullscreen]) #TabsToolbar:not(:-moz-lwtheme) {
>+    background-color: ActiveCaption;
>+    color: CaptionText;
>+  }
>+  #main-window[tabsintitlebar] #titlebar-content:not(:-moz-lwtheme):-moz-window-inactive,
>+  #main-window[tabsintitlebar]:not([inFullscreen]) #TabsToolbar:not(:-moz-lwtheme):-moz-window-inactive {
>+    background-color: InactiveCaption;
>+    color: InactiveCaptionText;
>+  }

>+  #main-window[tabsintitlebar] #titlebar:-moz-lwtheme {
>+    visibility: hidden;
>+  }
>+  #main-window[tabsintitlebar] #titlebar-content:-moz-lwtheme {
>+    -moz-binding: url("chrome://global/content/bindings/general.xml#windowdragbox");
>+    visibility: visible;
>+  }

Can you explain all of these styles?
(In reply to comment #307)
> Comment on attachment 499502 [details] [diff] [review]
> patch v4
> 
> >diff --git a/browser/base/content/browser.css b/browser/base/content/browser.css
> 
> >+#titlebar-spacer,
> >+#main-window[tabsintitlebar]:not([inFullscreen]) .tabbrowser-arrowscrollbox > scrollbox > .scrollbox-innerbox {
> >+  pointer-events: none;
> >+}
> >+
> >+.tabbrowser-tab,
> >+.tabs-newtab-button {
> >+  pointer-events: auto;
> >+}
> 
> Why is this needed?

To let clicks on the empty space restore the window rather than opening a blank tab.

> >diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js
> 
> >   _toggleAffectedChrome: function () {
> 
> Why this change?

Tabs can't be moved to the title bar while the toolbox is hidden.

> >+    let allowed = true;
> >+    for (let something in this._disallowed) {
> >+      allowed = false;
> >+      break;
> >+    }
> 
> let allowed = Object.keys(this._disallowed).length > 0; // ?

I considered this, seems less efficient.

> >+  uninit: function () {
> 
> >+    this._initialized = false;
> 
> Why is this flag needed?

_update() can be called before init() (via allowedBy()). We don't want to move the tab bar back and forth multiple times during startup, so we wait for init (and then for the resize event) before doing anything.

> >diff --git a/browser/themes/winstripe/browser/browser.css b/browser/themes/winstripe/browser/browser.css
> 
> >+%ifdef WINSTRIPE_AERO
> >+@media not all and (-moz-windows-compositor) {
> >+%endif
> >+  #main-window[tabsintitlebar] #titlebar-content:not(:-moz-lwtheme),
> >+  #main-window[tabsintitlebar]:not([inFullscreen]) #TabsToolbar:not(:-moz-lwtheme) {
> >+    background-color: ActiveCaption;
> >+    color: CaptionText;
> >+  }
> >+  #main-window[tabsintitlebar] #titlebar-content:not(:-moz-lwtheme):-moz-window-inactive,
> >+  #main-window[tabsintitlebar]:not([inFullscreen]) #TabsToolbar:not(:-moz-lwtheme):-moz-window-inactive {
> >+    background-color: InactiveCaption;
> >+    color: InactiveCaptionText;
> >+  }

This replaces the natively themed title bar, which would look odd in various ways depending on the OS theme when overlaying it with the tab bar.

> >+  #main-window[tabsintitlebar] #titlebar:-moz-lwtheme {
> >+    visibility: hidden;
> >+  }
> >+  #main-window[tabsintitlebar] #titlebar-content:-moz-lwtheme {
> >+    -moz-binding: url("chrome://global/content/bindings/general.xml#windowdragbox");
> >+    visibility: visible;
> >+  }

This hides the natively themed title bar when using a lightweight theme (as we already do for aero glass).

> Can you explain all of these styles?
Attached patch patchSplinter Review
addressed the nit. also updated to tip.
Attachment #499502 - Attachment is obsolete: true
Attachment #501824 - Flags: review?(gavin.sharp)
Attachment #499502 - Flags: review?(gavin.sharp)
Comment on attachment 501824 [details] [diff] [review]
patch

Bit worried about what kind of impact this will have on Txul... I guess that doesn't run maximized :(
Attachment #501824 - Flags: review?(gavin.sharp) → review+
blocking2.0: final+ → beta9+
http://hg.mozilla.org/mozilla-central/rev/019ae3c92eb4
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b9
I've poked around on all the menus but I can't see any obvious way to remove oneself from email notifications on a thread (like this one).  There must be a way to do this, right?
(In reply to comment #312)
> I've poked around on all the menus but I can't see any obvious way to remove
> oneself from email notifications on a thread (like this one).  There must be a
> way to do this, right?

Under the CC List section, click "Edit" then pick yourself from the list and be sure to check "Remove selected CCs", then click "Save Changes".
>.titlebar-placeholder[type="appmenu-button"] {
>  margin-left: 4px;
>}
>
>.titlebar-placeholder[type="caption-buttons"] {
>  margin-left: 10px;
>}

Shouldn't '-moz-margin-start' be used here instead?
(In reply to comment #314)
> >.titlebar-placeholder[type="appmenu-button"] {
> >  margin-left: 4px;
> >}
> >
> >.titlebar-placeholder[type="caption-buttons"] {
> >  margin-left: 10px;
> >}
> 
> Shouldn't '-moz-margin-start' be used here instead?

Won't make a difference.
Depends on: 624123
The top of tabs is not everywhere clickable: 8px from the left and 7px from the
right are not clickable.
Blocks: 624129
Blocks: 624128
Guys, while i think putting the tabs in the title bar is good and save space, I believe that this should be an option(I mean not everyone want tabs in the titlebar). So far I cannot turn it off... unless I put tabs at the bottom.
You can turn it off with browser.tabs.drawInTitlebar;false in about:config. It was mentioned several times in this bug.
I for one agree it should be an option. Wherever the settings for on top/bottom should be a third (default) to have them in the title bar.

So instead of a checkbook for on top, have three radio buttons for the three options, Tabs in Titlebar (if aero), Tabs on Top or Tabs on Bottom.

It may also be nice to have an option somewhere to have tabs-in-titlebar even when not maximized.
On windows classic theme it is very difficult read inactive tab title. See attachment. Why cant we use system colors for inactive window title there, as in general a MDI child window do that.
I would like to see tabs on title bar all the time. Is there a about:config for that ?
(In reply to comment #322)
> I would like to see tabs on title bar all the time. Is there a about:config for
> that ?

Nope, there is not. You can use a userstyle.
Verified fixed:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110108 Firefox/4.0b9pre
Status: RESOLVED → VERIFIED
(In reply to comment #321)
> Created attachment 502239 [details]
> tabs_on_top_inactive.png
> 
> On windows classic theme it is very difficult read inactive tab title. See
> attachment. Why cant we use system colors for inactive window title there, as
> in general a MDI child window do that.

This is bug Bug 569850, the patch for which has not yet landed.

In the meantime, try the following in your userChrome.css file:

.tabbrowser-tab:not([selected="true"]),
.tabs-newtab-button {
  background-image: -moz-linear-gradient(hsla(51,34%,89%,.9),
                    hsla(51,15%,79%,.9) 1px, hsla(51,9%,68%,.9) 60%)
                    !important;
}

.tabbrowser-tab:hover:not([selected="true"]),
.tabs-newtab-button:hover {
  background-image: -moz-linear-gradient(hsla(51,34%,100%,.9),
                    hsla(51,15%,94%,.9) 1px, hsla(51,9%,83%,.9) 60%)
                    !important;
}
Now that it's over... I wonder if we will see this on Mac in Firefox.next (please?)
I've just noticed a bug, but I'm not sure whether it's only on my end. Can anyone reproduce this?

Restore the window and resize it horizontally so that it's quite small. Then, maximise the window again. Do the scrolling arrows still remain, even though the tabs don't overflow?

If someone else can reproduce this, I'll file a bug.
(In reply to comment #327)
> I've just noticed a bug, but I'm not sure whether it's only on my end. Can
> anyone reproduce this?
> 
> Restore the window and resize it horizontally so that it's quite small. Then,
> maximise the window again. Do the scrolling arrows still remain, even though
> the tabs don't overflow?
> 
> If someone else can reproduce this, I'll file a bug.

Yes, I can reproduce it, following the steps you provided.
(In reply to comment #319)
> You can turn it off with browser.tabs.drawInTitlebar;false in about:config. It
> was mentioned several times in this bug.

but the average user would not know how to do that.
(In reply to comment #328)
> Yes, I can reproduce it, following the steps you provided.

Thanks. I'll a bug for it now.

(In reply to comment #329)
> (In reply to comment #319)
> > You can turn it off with browser.tabs.drawInTitlebar;false in about:config. It
> > was mentioned several times in this bug.
> 
> but the average user would not know how to do that.

For what it's worth, I agree that it should be added to the Options window. I think it's the sort of change that is significant enough that users should be able to modify it.
(In reply to comment #327)
> Restore the window and resize it horizontally so that it's quite small. Then,
> maximise the window again. Do the scrolling arrows still remain, even though
> the tabs don't overflow?

I have been seeing this for over a month. Maybe something in this bug(572160) was related to my userChrome.css
Don't know if a new bug was filed.
Depends on: 624157
No longer blocks: 624138
Depends on: 624138
I just wanted to chime in with the Tabs in Title Bar code I've been using in Stylish for a few months now and it works pretty good.

http://geeknik.pastebin.com/vTQcdzTR

And this bit of code turns tab bar buttons into tabs (home button, new tab button, tab group button, list all tabs, etc).

http://geeknik.pastebin.com/B1VdCEP7

Unfortunately, with all of that code, it makes the tab drop indictator when moving tabs around almost invisible, so I have to use this:

http://geeknik.pastebin.com/zkFgg24n

Just a side note, all of the buttons work like they should with this code, closing, opening, moving, tearing, double clicking on tab closes it, double clicking in open space of the title bar causes it to restore to it's previous size, or to maximize. I haven't had any issues with having to click in tiny little areas on a button to get it to work.
Depends on: 624148
Blocks: 624146
Depends on: 624225
Depends on: 624176
Depends on: 624251
Blocks: 624262
Depends on: 624287
(In reply to comment #317)
> Created attachment 502227 [details]
> top not clickable

Yes, on WinXP 1-2 pixels not clickable.
Background tabs need to use the CaptionText color to be readable over the title-bar background.
(In reply to comment #334)
> Background tabs need to use the CaptionText color to be readable over the
> title-bar background.

What platform and theme are you using? Follow-up bug?
Both XP and 2000 use dark colored titlebars.... and the same problem will likely occur in Vista if the user has a dark desktop background and using Glass.
(In reply to comment #336)
> Both XP and 2000 use dark colored titlebars.... and the same problem will
> likely occur in Vista if the user has a dark desktop background and using
> Glass.

I'm using Win 7 and have a dark desktop while using glass and don't see this. It seems worth filing as a follow up bug.
(In reply to comment #334)
> Background tabs need to use the CaptionText color to be readable over the
> title-bar background.

Isn't this Bug 569850 ?
It may be bug 624251?
I think I've read most of the comments - but I don't see any resolution for the aero snap issue.  Is the intent to leave it as-is, with aero snap largely unusable?  Or are the suggestions concerning gesture-based distinction between tab-tearing, tab-moving and aero snap being implemented?  For the record, I like aero snap, but I prefer this new behavior to an aero snap that's confusable with tab-tearing.

As a minor nitpick, it'd be nice if the visual tabs were also flush with the screen top when maximized - you can click there now, but it looks like there's a minor border (compare chrome).
I've lost the bug #, but someone suggested that at least the app button (Firefox button) be dragable for aero snap. It currently doesn't do anything on drag, and it is in the title bar, so while a little undiscovered, once your know it's there, it's a fairly large target.
Support @James, also I think other buttons of background color (left/right overflow buttons ("list all tabs") and "group your tabs" buttons) should also cause aero drag and snap.

Would Alt+drag on any tab be a good shortcut as well? This way I never have to aim for that little gap, instead could grab any tab and with Alt treat it as a whole window?  Ctrl is not as good as it usually implies "duplicate" tab.
No longer blocks: 624262
Depends on: 624262
(In reply to comment #333)
> (In reply to comment #317)
> > Created attachment 502227 [details]
> > top not clickable
> 
> Yes, on WinXP 1-2 pixels not clickable.

This is the case for Win7 as well.  The attachment overstates the case though (assuming that reporter and I are seeing the same thing.)
(In reply to comment #344)
> Created attachment 502515 [details]
> unclickable area (same in win7 and xp) doesn't trigger tab switch
> 
> (In reply to comment #333)
> > (In reply to comment #317)
> > > Created attachment 502227 [details]
> > > top not clickable
> > 
> > Yes, on WinXP 1-2 pixels not clickable.
> 
> This is the case for Win7 as well.  The attachment overstates the case though
> (assuming that reporter and I are seeing the same thing.)

Upon further investigation, this is not specific to tabs in titlebar. It's also problematic in restored windows. But I think it's a tad worse because of fitts law and how the unclickable space is actually rather wide at the very top of the frame.
(In reply to comment #344)
> Created attachment 502515 [details]
> unclickable area (same in win7 and xp) doesn't trigger tab switch
> 
> (In reply to comment #333)
> > (In reply to comment #317)
> > > Created attachment 502227 [details]
> > > top not clickable
> > 
> > Yes, on WinXP 1-2 pixels not clickable.
> 
> This is the case for Win7 as well.  The attachment overstates the case though
> (assuming that reporter and I are seeing the same thing.)

Check out Bug 624225
The number of regressions this is causing makes me wonder if it really needs to block Firefox 4; might be best to revert the change and wait until next time.
(In reply to comment #347)
> The number of regressions this is causing makes me wonder if it really needs to
> block Firefox 4; might be best to revert the change and wait until next time.

Curious, by "next time" are you referring to beta 10 or the next version of Firefox?
(Just for clarification.)
(In reply to comment #347)
> The number of regressions this is causing makes me wonder if it really needs to
> block Firefox 4; might be best to revert the change and wait until next time.

What regressions are we talking about? There were some issues that since this landing has been highlighted, but those things should've been on the to-do list for FF4 anyway. We also have the UI issues that again, needed dealing with anyway. This is one of the huge features that helps us maintain our image as a modern browser. We really can't afford to ship FF4 and be the only browser of this generation without tabs in titlebar.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(In reply to comment #346)
> (In reply to comment #344)
> > Created attachment 502515 [details]
> > unclickable area (same in win7 and xp) doesn't trigger tab switch
> > 
> > (In reply to comment #333)
> > > (In reply to comment #317)
> > > > Created attachment 502227 [details]
> > > > top not clickable
> > > 
> > > Yes, on WinXP 1-2 pixels not clickable.
> > 
> > This is the case for Win7 as well.  The attachment overstates the case though
> > (assuming that reporter and I are seeing the same thing.)
> 
> Check out Bug 624225

i dont feel its wrong , even chrome behaves the same (do note this bug is parity chrome) , http://img521.imageshack.us/img521/4153/45728098.png
This bug was reopened without comment after being VERIFIED.  Moving back to RESOLVED; please open new bugs if you are still seeing problems related to this change.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
What exactly is resolved with this bug?  I still don't see any tab movement indicators in full sreen with the current Hourly (http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/1294769515-20110111101155-62e195a65ff3-firefox-4.0b10pre.en-US.win32.zip) File Time = 12:35.
Read the bug title. Are tabs in the title bar when maximized?
Bug's resolved. Move on and file new bugs if you want.
(In reply to comment #352)
> What exactly is resolved with this bug?  I still don't see any tab movement
> indicators in full sreen with the current Hourly
> (http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/1294769515-20110111101155-62e195a65ff3-firefox-4.0b10pre.en-US.win32.zip)
> File Time = 12:35.

You've already complained in the other bug, which this already shows as a dependency. Not all dependencies need to be "resolved" in order to mark this bug resolved, since tabs ARE now in the titlebar.
Depends on: 625888
Depends on: 625324
Depends on: 626014
No longer depends on: 626014
Depends on: 624778
Depends on: 626214
Depends on: 626268
Depends on: 626221
No longer depends on: 626214
Depends on: 626601
No longer depends on: 626601
No longer depends on: 624138
No longer depends on: 624262
No longer depends on: 624287
Depends on: 627986
Depends on: 624292
No longer depends on: 626268
Has there been any progress on getting an indicator of tab location back in when reordering? The beta cycles are winding down now, and there doesn't really seem to be a specific bug for this anywhere (since the more grandiose one for animated tab reordering got back-burnered).
(In reply to comment #356)

bug 606909
Depends on: 632767
Depends on: 634213
No longer depends on: 634213
No longer depends on: 625324, 625888, 632767
No longer depends on: 624176, 624251, 624778
Depends on: 635624
No longer depends on: 635624
Depends on: 636779
No longer depends on: 636779
Verified fixed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre
Missing unclickable area that is shown in an attachments:
https://bugzilla.mozilla.org/attachment.cgi?id=502515
https://bugzilla.mozilla.org/attachment.cgi?id=502227

It completely removed? Will it be returned?
Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110704 Firefox/7.0a1
was fixed with bug 624225
(In reply to comment #360)
> was fixed with bug 624225

Ok. Thank you for your reply.
Will tabs on title bar be available on linux ?
(In reply to comment #362)
> Will tabs on title bar be available on linux ?

it depends on the window manager, it's covered in bug 513159
You need to log in before you can comment on or make changes to this bug.