572160 - Put tabs in the title bar when the window is maximized

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[Peter Henkel [:Terepin]]

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

Comment 1

[Peter Henkel [:Terepin]]

Attachment: App Button in Title Bar mockup

Comment 2

[Paul [pwd]]

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.

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Mockup of the maximized state

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

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).

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

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)

Comment 8

[Peter Henkel [:Terepin]]

Alex, could you comment Bug 571785?

Comment 9

[Edward Asquith]

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?

Comment 10

[Peter Henkel [:Terepin]]

That is why it's being called "Add OPTION for placing tabs into Title Bar when window is maximized" you know.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

>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).

Comment 12

[Edward Asquith]

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.

Comment 13

[Tan Wei Lin Jason [:Ryuji]]

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.

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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;
}

Comment 15

[Peter Henkel [:Terepin]]

Working good.

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 17

[Tan Wei Lin Jason [:Ryuji]]

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?

Comment 18

[Ferdinand]

Is the new orange Firefox not an ideal target for Aero-snap dragging?

Comment 19

[Paul McAuley]

(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.

Comment 20

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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.

Comment 21

[imradyurrad]

(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?

Comment 22

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Attachment: Windows Live Movie Maker

This is the non-maximized version.

When it's maximized, the button uses the full height of the titlebar.

Comment 23

[Paul McAuley]

(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.

Comment 24

[Paul McAuley]

(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.

Comment 25

[Alex Faaborg [:faaborg] (Firefox UX)]

>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).

Comment 26

[Paul McAuley]

(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.

Comment 27

[Peter Henkel [:Terepin]]

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.

Comment 28

[Alex Faaborg [:faaborg] (Firefox UX)]

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

Comment 29

[Tan Wei Lin Jason [:Ryuji]]

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.

Comment 30

[Alex Faaborg [:faaborg] (Firefox UX)]

right, I meant that at a minimum this should block final.

Comment 31

[Tan Wei Lin Jason [:Ryuji]]

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.

Comment 32

[[e-mail]]

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

Comment 33

[[e-mail]]

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

Comment 34

[aicitman]

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.

Comment 36

[imradyurrad]

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.

Comment 37

[[not reading bugmail]]

(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.

Comment 38

[Ivan Stetsenko]

>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.

Comment 39

[aicitman]

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.

Comment 40

[Johnathan Nightingale [:johnath]]

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.

Comment 41

[Jim Mathies [:jimm]]

(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.

Comment 42

[Peter Henkel [:Terepin]]

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.)

Comment 43

[Joshua M [:soapy]]

Attachment: Tabs in titlebar when maximized v1

Puts tabs in titlebar when maximized as show in the mockup.

Comment 44

[Edo Karabas]

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;
}

Comment 45

[Paul [pwd]]

(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.

Comment 46

[Paul McAuley]

(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#

Comment 47

[Paul McAuley]

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).

Comment 48

[imradyurrad]

(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.

Comment 49

[Paul McAuley]

> 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?!).

Comment 50

[Paul McAuley]

(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?

Comment 51

[Paul McAuley]

(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

Comment 52

[Paul McAuley]

(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.

Comment 53

[Tan Wei Lin Jason [:Ryuji]]

Ideally tabs in the title bar should leave some space to allow user to drag Titlebar.

Comment 54

[Mitchell Field [:Mitch]]

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).

Comment 55

[Paul McAuley]

(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.

Comment 56

[Mike Beltzner [:beltzner, not reading bugmail]]

Really-really-want, but given the problems we've had with drawing in the titlebar, I can't see us block on this.

Comment 57

[Alex Limi (:limi) — Firefox UX Team]

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?

Comment 58

[Alex Limi (:limi) — Firefox UX Team]

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 59

[Jim Mathies [:jimm]]

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?

Comment 60

[Dão Gottwald [:dao]]

Comment on attachment 465999 [details] [diff] [review]
Tabs in titlebar when maximized v1

Does this still work now that bug 575870 relanded?

Comment 61

[Nochum Sossonko [:Natch]]

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.

Comment 62

[Paul [pwd]]

CC'ing in Joshua M since comments are now being directed at him.

Comment 63

[Alex Limi (:limi) — Firefox UX Team]

(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!

Comment 64

[Peter Henkel [:Terepin]]

(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.

Comment 65

[Paul [pwd]]

(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?

Comment 66

[Peter Henkel [:Terepin]]

I dunno, I only saw other user's reports from Mozillazine forums.

Comment 67

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(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.

Comment 68

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Er, s/userscript/userstyle/

Comment 69

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 70

[Paul [pwd]]

(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?

Comment 71

[Alex Limi (:limi) — Firefox UX Team]

(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?

Comment 72

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(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.

Comment 73

[Mike Beltzner [:beltzner, not reading bugmail]]

(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. :)

Comment 74

[Paul McAuley]

> 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.

Comment 75

[Jim Mathies [:jimm]]

(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.

Comment 76

[Peter Henkel [:Terepin]]

(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.

Comment 77

[Peter Henkel [:Terepin]]

(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.

Comment 78

[Paul [pwd]]

(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.

Comment 79

[Peter Henkel [:Terepin]]

Firefox is about choices. Of course, I could write many more reasons why to keep old menu, but this surpass everything else.

Comment 80

[Johnathan Nightingale [:johnath]]

(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

Comment 81

[Peter Henkel [:Terepin]]

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.

Comment 82

[Paul [pwd]]

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.

Comment 83

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 84

[Alex Limi (:limi) — Firefox UX Team]

Joshua M said he will take a look at this. Yay!

Comment 85

[Joshua M [:soapy]]

Attachment: Tabs in titlebar when maximized v2

Comment 86

[Dão Gottwald [: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?

Comment 87

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 88

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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 89

[Csaba Kozák [:WonderCsabo]]

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 90

[Csaba Kozák [:WonderCsabo]]

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

Comment 91

[David Naylor]

(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?

Comment 92

[Paul [pwd]]

(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.

Comment 93

[David Naylor]

(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.

Comment 94

[Paul [pwd]]

(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.

Comment 95

[David Naylor]

(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.

Comment 96

[Csaba Kozák [:WonderCsabo]]

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?

Comment 97

[Csaba Kozák [:WonderCsabo]]

It was me, sorry...

Comment 98

[Alex Limi (:limi) — Firefox UX Team]

(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. :)

Comment 99

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 100

[imradyurrad]

(In reply to comment #99)

Funny...I just filed bug 592450 about that some odd hours ago.

Comment 101

[Paul McAuley]

Attachment: A proposal to allow both window dragging and tab tear-off

(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.

Comment 102

[Alex Limi (:limi) — Firefox UX Team]

(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. :)

Comment 103

[Paul McAuley]

(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.

Comment 104

[Paul McAuley]

> 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.

Comment 105

[Paul [pwd]]

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?

Comment 106

[Joshua M [:soapy]]

Attachment: Tabs in titlebar when maximized v3

-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.

Comment 107

[Dão Gottwald [: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?

Comment 108

[Csaba Kozák [:WonderCsabo]]

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 )

Comment 109

[Dão Gottwald [:dao]]

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?)

Comment 110

[Csaba Kozák [:WonderCsabo]]

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.

Comment 111

[Daniel Spiewak]

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.

Comment 112

[Valerio]

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;
}

Comment 113

[Csaba Kozák [:WonderCsabo]]

(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.

Comment 114

[Peter Henkel [:Terepin]]

This bug is at least for Aero Glass.

Comment 115

[Csaba Kozák [:WonderCsabo]]

Nope. It should apply to Aero Basic, too. (if i read Dao's reviews correctly)

Comment 116

[Csaba Kozák [:WonderCsabo]]

Or this is what you say with "at least"?

(sorry for double post...)

Comment 117

[Peter Henkel [:Terepin]]

Yep. It would be great if it could cover all Win versions and their themes.

Comment 118

[Valerio]

My solution works with aero glass and aero basic...

Comment 119

[Peter Henkel [:Terepin]]

What about XP, 2000 and Classic theme?

Comment 120

[Csaba Kozák [:WonderCsabo]]

I know that, just Dao is sceptic about that...

Comment 121

[Valerio]

I have windows 7 but if I set the classic theme it works...

Comment 122

[Valerio]

someone with xp should try?

Comment 123

[Paul [pwd]]

This bug is marked Windows 7. We should file seperate bugs for other OS.

Comment 124

[Peter Henkel [:Terepin]]

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.

Comment 125

[Mike Beltzner [:beltzner, not reading bugmail]]

Felipe: any way you can help with this? You've shown proficency with this type of thing in the past!

Comment 126

[Jim Mathies [:jimm]]

(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?)

Comment 127

[Joshua M [:soapy]]

How should Tab Candy look when the window is maximized? That's the issue I'm currently stuck on.

Comment 128

[José Jeria]

Why not same as now?

Comment 129

[Csaba Kozák [:WonderCsabo]]

(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.

Comment 130

[Dão Gottwald [:dao]]

(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.

Comment 132

[Jim Mathies [:jimm]]

(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.

Comment 133

[Dão Gottwald [:dao]]

In browser-aero.css using windows-default-theme and !windows-compositor.

Comment 134

[:Felipe Gomes (needinfo for replies!)]

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).

Comment 135

[:Felipe Gomes (needinfo for replies!)]

> 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..)

Comment 136

[Jim Mathies [:jimm]]

(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.

Comment 137

[:Felipe Gomes (needinfo for replies!)]

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.

Comment 138

[Jim Mathies [:jimm]]

(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.

Comment 139

[Csaba Kozák [:WonderCsabo]]

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.

Comment 140

[Joshua M [:soapy]]

(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.

Comment 141

[Csaba Kozák [:WonderCsabo]]

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?

Comment 142

[Joshua M [:soapy]]

(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.

Comment 143

[Csaba Kozák [:WonderCsabo]]

Ok, thanks.

The screen edge issue is decided?

Comment 144

[Csaba Kozák [:WonderCsabo]]

Joshua, have you succeed with the fix?

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

Comment 145

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 146

[Csaba Kozák [:WonderCsabo]]

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.

Comment 147

[David Naylor]

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).

Comment 148

[Paul [pwd]]

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.

Comment 149

[David Naylor]

Attachment: Chrome leaves space right of tabs

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).

Comment 150

[Csaba Kozák [:WonderCsabo]]

(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

Comment 151

[Paul [pwd]]

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.

Comment 152

[David Naylor]

> (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.

Comment 153

[Paul [pwd]]

Attachment: Mockup of dropping tab idea

Comment 154

[Csaba Kozák [:WonderCsabo]]

I definitely dont like either idea, David is correct, we should wait for Alex's comments.

Comment 155

[Paul [pwd]]

Could we not land this and deal with the usability issue in a follow-up bug?

Comment 156

[ronin.achilles]

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.

Comment 157

[ronin.achilles]

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.

Comment 158

[Alex Limi (:limi) — Firefox UX Team]

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 159

[Dão Gottwald [:dao]]

Comment on attachment 471805 [details] [diff] [review]
Tabs in titlebar when maximized v3

This patch is obsolete.

Comment 160

[Alex Limi (:limi) — Firefox UX Team]

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. :)

Comment 161

[Dão Gottwald [:dao]]

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.

Comment 163

[Alex Limi (:limi) — Firefox UX Team]

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

Comment 164

[Dão Gottwald [:dao]]

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".

Comment 165

[Csaba Kozák [:WonderCsabo]]

(In reply to comment #163)
> Feedback from shorlander:
> 
> > it doesn't work at all without glass

What do you mean? 
http://tinyurl.com/38m36nx

Comment 166

[David Naylor]

(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.

Comment 167

[jcspence74]

@Dao

So are you working on a new patch?

Comment 168

[jvbferrer]

Any aproximate date to see this bug fixed on Minefield?

Comment 169

[:Felipe Gomes (needinfo for replies!)]

Attachment: Tabs in titlebar

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.

Comment 170

[Csaba Kozák [:WonderCsabo]]

It still doesnt take into account this: http://tinyurl.com/34hyf9d

Comment 171

[:Felipe Gomes (needinfo for replies!)]

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

Comment 172

[Csaba Kozák [:WonderCsabo]]

Alex, what's your thoughts on this?

Felipe: Does this work with popup windows?

Comment 173

[:Felipe Gomes (needinfo for replies!)]

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?

Comment 174

[Csaba Kozák [:WonderCsabo]]

Click on my username (WonderCsabo) here.

http://itcafe.hu/tema/mozilla_firefox_2/hsz_14147-14147.html

Comment 175

[Alex Faaborg [:faaborg] (Firefox UX)]

>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?

Comment 176

[Csaba Kozák [:WonderCsabo]]

(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.

Comment 177

[:Felipe Gomes (needinfo for replies!)]

Attachment: Patch v2

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.

Comment 178

[:Felipe Gomes (needinfo for replies!)]

(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.

Comment 179

[Bruno Faria]

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...

Comment 180

[jvbferrer]

Why is this bug taking so much time?

Comment 181

[Mike Beltzner [:beltzner, not reading bugmail]]

(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.

Comment 182

[Csaba Kozák [:WonderCsabo]]

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.

Comment 183

[Csaba Kozák [:WonderCsabo]]

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?

Comment 184

[Tim Meader]

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?

Comment 185

[Carlos Alén Silva]

(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)

Comment 186

[Bill Gianopoulos [:WG9s]]

(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.

Comment 187

[Paul [pwd]]

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.

Comment 188

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 189

[Tiago Sá]

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.

Comment 190

[Dão Gottwald [:dao]]

Attachment: patch

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?

Comment 191

[Dão Gottwald [:dao]]

Attachment: patch

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.

Comment 192

[Dão Gottwald [:dao]]

Comment on attachment 490586 [details] [diff] [review]
patch

try server build: http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-5b0c1f475b89/tryserver-win32/firefox-4.0b8pre.en-US.win32.zip

Comment 193

[Peter Henkel [:Terepin]]

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.

Comment 194

[Siddhartha Dugar [:sdrocking]]

There is some extra space on both ends of the tab strip.[Win7]

Comment 195

[Tim Meader]

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.

Comment 196

[Fritz]

Attachment: Spacing with buttons in different states

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.

Comment 197

[Norman Paschke]

Looks great, another small glitch: tab overflow button on the left is placed between app tabs and the rest of the normal tabs

Comment 198

[Csaba Kozák [:WonderCsabo]]

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 199

[:Felipe Gomes (needinfo for replies!)]

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.

Comment 200

[Siddhartha Dugar [:sdrocking]]

Menubar(Alt+F) is not visible completely.

Comment 201

[Siddhartha Dugar [:sdrocking]]

The firefox button changes size too often, for instance during panorama view, customize view, restored window. The size needs to be fixed.

Comment 202

[jcspence74]

(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.

Comment 203

[Paul McAuley]

(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?

Comment 204

[Tim Meader]

(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.

Comment 205

[Paul McAuley]

(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).

Comment 206

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 207

[Tim Meader]

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)?

Comment 208

[imradyurrad]

That will be fixed by bug 455694.

Comment 209

[Fritz]

(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.

Comment 210

[Alex Faaborg [:faaborg] (Firefox UX)]

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).

Comment 211

[Paul McAuley]

(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.

Comment 212

[Dão Gottwald [:dao]]

(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).

Comment 213

[Dão Gottwald [:dao]]

Attachment: patch v2

Comment 214

[Alex Faaborg [:faaborg] (Firefox UX)]

>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?

Comment 215

[Paul [pwd]]

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.

Comment 216

[Dão Gottwald [:dao]]

Comment on attachment 490827 [details] [diff] [review]
patch v2

updated try build: http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-8d431f0330f7/tryserver-win32/firefox-4.0b8pre.en-US.win32.zip

Comment 217

[Dão Gottwald [:dao]]

(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.

Comment 218

[Valerio]

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

Comment 219

[Dão Gottwald [:dao]]

Attachment: patch v3

fixed the print preview bug

Comment 220

[Tim Meader]

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).

Comment 221

[Dão Gottwald [:dao]]

(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.

Comment 222

[Vova Olar]

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?

Comment 223

[bogas04]

Why not just add a pref ? 

For eg : http://img88.imageshack.us/img88/1232/34205427.png

Comment 224

[Dão Gottwald [:dao]]

Comment on attachment 490872 [details] [diff] [review]
patch v3

http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-1b2d2b092067/tryserver-win32/firefox-4.0b8pre.en-US.win32.zip

Comment 225

[Siddhartha Dugar [:sdrocking]]

Should Bug 574859 be considered while fixing this bug?

Comment 226

[Josh Tumath]

(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.

Comment 227

[Zio_Fede]

Right clicking the title bar does not bring up the system menu on Windows xp with tabs in the title bar.

Comment 228

[Csaba Kozák [:WonderCsabo]]

Dao: Comment 198 is still here.

Comment 229

[Edo Karabas]

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.

Comment 230

[Tim Meader]

(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.

Comment 231

[Dão Gottwald [:dao]]

(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.

Comment 232

[Edward Asquith]

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?

Comment 233

[JackieKu]

(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.

Comment 234

[bogas04]

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 :)

Comment 235

[Paul [pwd]]

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?

Comment 236

[[Baboo]]

(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.

Comment 237

[Siddhartha Dugar [:sdrocking]]

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?

Comment 238

[Matt Cosentino]

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.

Comment 239

[David Hsu]

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?

Comment 240

[Tim Meader]

(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.

Comment 241

[Red Adaya]

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.

Comment 242

[Matt Wood]

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.

Comment 243

[Paul [pwd]]

(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.

Comment 244

[David Naylor]

(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.)

Comment 245

[Matt Cosentino]

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 246

[Red Adaya]

@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 247

[Alex Faaborg [:faaborg] (Firefox UX)]

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).

Comment 248

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Padding on the right side of the Firefox button at 8x

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).

Comment 249

[Dão Gottwald [:dao]]

Attachment: patch v4

Reduced the padding as per comment 248.

Comment 250

[Matt Cosentino]

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.

Comment 251

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(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.

Comment 252

[Siddhartha Dugar [:sdrocking]]

(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.

Comment 253

[Matt Cosentino]

(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.

Comment 254

[David Hsu]

(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.

Comment 255

[Alex Limi (:limi) — Firefox UX Team]

(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.

Comment 256

[Frank Yan (:fryn)]

(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.

Comment 257

[Tim Meader]

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.

Comment 258

[Dão Gottwald [:dao]]

Attachment: patch v4

updated to tip

Comment 259

[Can]

is there a tryserver build for patch v4 ? I want to test latest change.

Comment 260

[Bill Gianopoulos [:WG9s]]

(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/

Comment 261

[Can]

(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.

Comment 262

[Zio_Fede]

(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...

Comment 263

[Bill Gianopoulos [:WG9s]]

The build sure works for me.  Are you sure you had the window maximized?  Tabs are only in the title bar on maximized windows.

Comment 264

[Mardeg]

Bill's build also works for me in maximised windows when the Menu bar is not ticked

Comment 265

[Zio_Fede]

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/

Comment 266

[Dietrich Ayala (:dietrich)]

Blocking+ per comment #28 and #57, which clearly show this is "a user experience problem deemed significant by the user experience team".

Comment 267

[Dan Cardin]

http://i55.tinypic.com/313rvqq.jpg

i use a non standard theme...

Comment 268

[Dão Gottwald [:dao]]

(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.

Comment 269

[Zio_Fede]

(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...

Comment 270

[Bill Gianopoulos [:WG9s]]

(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.

Comment 271

[Amiram]

is there a reason why this patch didn't get review ?

Comment 272

[Dan Cardin]

double clicking maximizes the window rather than opening a new tab, which is what i expected.

Comment 273

[Csaba Kozák [:WonderCsabo]]

(In reply to comment #272)
> double clicking maximizes the window rather than opening a new tab, which is
> what i expected.

Bug 575248

Comment 274

[Dan Cardin]

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.

Comment 275

[Bill Gianopoulos [:WG9s]]

Attachment: screenshot Windows/XP Luna

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.

Comment 276

[Dão Gottwald [:dao]]

(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

Comment 277

[Paul Herron]

The group tabs button should be moved so it remains in the title bar when the group tabs button is clicked.

Comment 279

[Dão Gottwald [:dao]]

Attachment: patch v4

updated to tip

Comment 280

[don wood]

Gosh, I feel so... unlearned. How would one go about applying one of the above mentioned patches?

Comment 281

[Dão Gottwald [:dao]]

(In reply to comment #280)
> Gosh, I feel so... unlearned. How would one go about applying one of the above
> mentioned patches?

https://developer.mozilla.org/En/Developer_Guide/Source_Code
https://developer.mozilla.org/en/Mercurial_FAQ#How_can_I_diff_and_patch_files.3f
https://developer.mozilla.org/en/build_documentation

Comment 282

[don wood]

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/

Comment 283

[Csaba Kozák [:WonderCsabo]]

Please do not post screenshots of a customized theme. It's confusing.

Middle click is working for me.

Comment 284

[Matt Sturgeon]

I posted some css , for use in xul, in bug 620303. i was however told that it was appropriate only for maximized views...

Comment 285

[cris]

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.

Comment 286

[Ferdinand]

(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.

Comment 287

[cris]

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.

Comment 288

[Paul [pwd]]

(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.

Comment 289

[cris]

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".

Comment 290

[Bill Gianopoulos [:WG9s]]

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.

Comment 291

[Csaba Kozák [:WonderCsabo]]

Bug 575248

Comment 292

[don wood]

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.)

Comment 293

[Matt Sturgeon]

I (personally) agree. but I'd like to hear the logic behind the decision.

Comment 294

[Csaba Kozák [:WonderCsabo]]

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

Comment 295

[Emanuel Hoogeveen [:ehoogeveen]]

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).

Comment 296

[Csaba Kozák [:WonderCsabo]]

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.

Comment 297

[Jonathan Haas]

(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.

Comment 298

[don wood]

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!

Comment 299

[Carlos Alén Silva]

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.

Comment 300

[Jojo]

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.

Comment 301

[Jojo]

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?

Comment 302

[imradyurrad]

You're welcome to stay on 3.6 if you want. 
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 303

[Bill Gianopoulos [:WG9s]]

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.

Comment 304

[bogas04]

(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 :)

Comment 305

[bgzllbs]

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

Comment 306

[Bill Gianopoulos [:WG9s]]

(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 307

[:Gavin Sharp [email: [e-mail]]]

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?

Comment 308

[Dão Gottwald [:dao]]

(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?

Comment 309

[Dão Gottwald [:dao]]

Attachment: patch

addressed the nit. also updated to tip.

Comment 310

[:Gavin Sharp [email: [e-mail]]]

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 :(

Comment 311

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/019ae3c92eb4

Comment 312

[Jojo]

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?

Comment 313

[Tim Meader]

(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".

Comment 314

[Joshua M [:soapy]]

>.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?

Comment 315

[Dão Gottwald [:dao]]

(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.

Comment 316

[Florian J. [:FeuerFliege]]

The top of tabs is not everywhere clickable: 8px from the left and 7px from the
right are not clickable.

Comment 317

[Florian J. [:FeuerFliege]]

Attachment: top not clickable

Comment 318

[Tan Wei Lin Jason [:Ryuji]]

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.

Comment 319

[Csaba Kozák [:WonderCsabo]]

You can turn it off with browser.tabs.drawInTitlebar;false in about:config. It was mentioned several times in this bug.

Comment 320

[Matt Sturgeon]

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.

Comment 321

[Biju]

Attachment: 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.

Comment 322

[Biju]

I would like to see tabs on title bar all the time. Is there a about:config for that ?

Comment 323

[Csaba Kozák [:WonderCsabo]]

(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.

Comment 324

[u88484]

Verified fixed:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110108 Firefox/4.0b9pre

Comment 325

[Bill Gianopoulos [:WG9s]]

(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;
}

Comment 326

[David Hsu]

Now that it's over... I wonder if we will see this on Mac in Firefox.next (please?)

Comment 327

[Josh Tumath]

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.

Comment 328

[bgzllbs]

(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.

Comment 329

[Tan Wei Lin Jason [:Ryuji]]

(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.

Comment 330

[Josh Tumath]

(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.

Comment 331

[Siddhartha Dugar [:sdrocking]]

(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.

Comment 332

[Brian Carpenter [:geeknik]]

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.

Comment 333

[pumay]

(In reply to comment #317)
> Created attachment 502227 [details]
> top not clickable

Yes, on WinXP 1-2 pixels not clickable.

Comment 334

[patrickjdempsey]

Background tabs need to use the CaptionText color to be readable over the title-bar background.

Comment 335

[Paul [pwd]]

(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?

Comment 336

[patrickjdempsey]

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.

Comment 337

[Paul [pwd]]

(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.

Comment 338

[Siddhartha Dugar [:sdrocking]]

(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 ?

Comment 339

[Paul [pwd]]

It may be bug 624251?

Comment 340

[Eamon Nerbonne]

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).

Comment 341

[James May [:fowl2]]

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.

Comment 342

[Yuri Astrakhan]

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.

Comment 344

[Asa Dotzler [:asa]]

Attachment: 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.)

Comment 345

[Asa Dotzler [:asa]]

(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.

Comment 346

[Csaba Kozák [:WonderCsabo]]

(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

Comment 347

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 348

[Caspy7]

(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.)

Comment 349

[Paul [pwd]]

(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.

Comment 350

[bogas04]

(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

Comment 351

[Matt Brubeck (:mbrubeck)]

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.

Comment 352

[Chris B.]

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.

Comment 353

[imradyurrad]

Read the bug title. Are tabs in the title bar when maximized?
Bug's resolved. Move on and file new bugs if you want.

Comment 354

[Tim Meader]

(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.

Comment 355

[pumay]

Attachment: Non-clickable areas on top tabs when the window is maximized in Windows XP.

Comment 356

[Tim Meader]

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).

Comment 357

[Dão Gottwald [:dao]]

(In reply to comment #356)

bug 606909

Comment 358

[Vlad [QA]]

Verified fixed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre

Comment 359

[VeRtex]

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

Comment 360

[Florian J. [:FeuerFliege]]

was fixed with bug 624225

Comment 361

[VeRtex]

(In reply to comment #360)
> was fixed with bug 624225

Ok. Thank you for your reply.

Comment 362

[x]

Will tabs on title bar be available on linux ?

Comment 363

[Antoine Turmel [:GeekShadow]]

(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