For the new Firefox theme/UI we would like to place the Tabs above the Navigation Bar by default. This would be beneficial for the following reasons: * Gives Firefox a correct UI hierarchy where the controls are tab specific * Fix a redundancy in having both a titlebar with page title as well as a tab with the page title * A Fitt's Law win if the window is maximized * A small vertical space savings allowing more room for content * Creates a more streamlined UI The ability to have Tabs underneath the Navigation Bar would also be needed. Potential entry points for this preference could be in a contextual menu on the tab bar, under the tab preferences pane or more ideally in the Customization dialog. The Customization dialog would need to be reworked to fit in this option. See attachment for mockup.

Steven, Is there a group or news group where this is being discussed? I want to express my concerns about this change. Thanks.

(In reply to comment #1) > Steven, > > Is there a group or news group where this is being discussed? I want to express > my concerns about this change. Thanks. There have been discussions on this previously on the Newsgroup and the Wiki: Newsgroup: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/9e569626887ae703?tvc=2&q=Proposed+Direction Wiki: https://wiki.mozilla.org/Talk:Firefox/4.0_Windows_Theme_Mockups There isn't a d.a.f post for this specific change though.

Thanks.

Should note that the default window configuration will vary by platform in order to fit in interactively with all of the other apps the user regularly uses on that platform. Windows 2000: tab bar below, traditional menu bar Windows XP: tab bar below, traditional menu bar Windows Vista: tab bar above, application button Windows 7: tab bar above, application button OS X: tab bar below, menu bar at top of screen Linux: [we have no idea, we don't want to appear "old" at the cost of being native, but Chrome is now picking some some shiny points by ignoring native interactive design. Distros will also be able to control the way Firefox is deployed, so to some extent we don't have to make this call ourselves]

(In reply to comment #4) > Should note that the default window configuration will vary by platform in > order to fit in interactively with all of the other apps the user regularly > uses on that platform. > > Windows 2000: tab bar below, traditional menu bar > Windows XP: tab bar below, traditional menu bar > Windows Vista: tab bar above, application button > Windows 7: tab bar above, application button Which other apps with regards to the tab bar position?

there are tabs on top with Paint and WordPad on Windows 7

Really? Is this for multiple documents or ribbon?

This is for the ribbon, the only native app I know who use multiple documents is IE and the tab bar is below.

>Which other apps with regards to the tab bar position? In terms of interactive consistency I was thinking more about the application button than tabs on top (since multiple documents isn't really the same thing as ribbon, interactively speaking). The application button doesn't necessarily have to be tied to the placement of the tabs. Tabs can really be in any configuration with the application button present. In terms of visual consistency, using tabs on top for documents is visually kind of similar to the ribbon layout (although really not the same interactively). This is I think why there were erroneous press reports that we were going to deploy a ribbon interface, primarily due to the visual consistency.

(In reply to comment #9) > In terms of visual consistency, using tabs on top for documents is visually > kind of similar to the ribbon layout (although really not the same > interactively). That's a pretty big "although". I thought we wanted this because it fit our interaction model better, but presumably this would apply across platforms. I really think this needs to be backed by usability considerations strong enough to not depend on the ribbon (non-)simile, anyway.

I was just explaining what I meant when I was referring to external consistency (of the application button). In terms of rational for placing tabs on top for on modern versions of Windows: Pros: -Clear conceptual model (back/forward effect the tab, not the application) -Externally consistent with actual physical tabs -Ability to create chromeless application tabs and home tab -Visually simpler (less redundancy with title and favicon) -Easy to distinguish from IE at a glance Cons: -Minor efficiency loss due to the mouse having to travel slightly farther (it would be great to run a Test Pilot study on this so we can understand exactly what the difference costs in terms of average time for tab selection with the mouse) -Harder to distinguish from Chrome (which is admittedly less common of a situation than distinguishing from IE). Unrelated to Usability: -There is a general perception that placing tabs in a more conceptually pure configuration is "modern and sleek" while the traditional placement is "old and clunky." This is purely an emotional design and brand level consideration, primarily caused by Chrome being the "new" product in the marketplace, and Firefox presently being the "old" product in the marketplace. Had we made the change with Firefox 3 on Vista, we would not currently be facing this situation. However we are now at a state where deploying the more conceptually pure design is "copying" or "catching up," and failing to deploy it may be interpreted as "stagnating" or "falling behind." The product perception issues related to tab placement appear to be a lose/lose at this point.

(In reply to comment #11) > I was just explaining what I meant when I was referring to external consistency > (of the application button). In terms of rational for placing tabs on top for > on modern versions of Windows: > > Pros: > -Clear conceptual model (back/forward effect the tab, not the application) > -Externally consistent with actual physical tabs > -Ability to create chromeless application tabs and home tab > -Visually simpler (less redundancy with title and favicon) These are all OS-independent. (Actually, I don't understand the second point, does this refer to ribbon again?) > -Easy to distinguish from IE at a glance This one indeed is OS-dependent, but I'm sure it's not a deciding factor. > Cons: > -Minor efficiency loss due to the mouse having to travel slightly farther (it > would be great to run a Test Pilot study on this so we can understand exactly > what the difference costs in terms of average time for tab selection with the > mouse) This is the most common argument against tabs on top, and yes, it would be very helpful to meet it with some hard facts. > -Harder to distinguish from Chrome (which is admittedly less common of a > situation than distinguishing from IE). > > Unrelated to Usability: > -There is a general perception that placing tabs in a more conceptually pure > configuration is "modern and sleek" while the traditional placement is "old and > clunky." This is purely an emotional design and brand level consideration, > primarily caused by Chrome being the "new" product in the marketplace, and > Firefox presently being the "old" product in the marketplace. Had we made the > change with Firefox 3 on Vista, we would not currently be facing this > situation. However we are now at a state where deploying the more conceptually > pure design is "copying" or "catching up," and failing to deploy it may be > interpreted as "stagnating" or "falling behind." The product perception issues > related to tab placement appear to be a lose/lose at this point. This is also OS-independent. So... some users who're probably using Chrome already would say we stagnate. I think that's ok, as long as the rest appreciates the consistency and as long as we refresh the look regardless of the tabs' position. I'm not saying that we cannot move the tab bar, but we should have good reasons beyond a vague coolness factor.

(In reply to comment #12) > I'm not saying that we cannot move the tab bar, but we should have good reasons > beyond a vague coolness factor. Wouldn't the most reasonable solution be to fix bug 347930? Then people can do with the tab bar whatever floats their boat. Then this debate would be pretty much moot.

The debate is about the default position. But I agree that just making it customizable could satisfy the users who'd think we're stagnating.

>IU: Then people can do with the tab bar whatever floats their boat. Then >this debate would be pretty much moot. We want the arrangement to be fully customizable by the user, so we won't be taking away any control. However the debate is more specifically about what default interface we want to ship to users on each platform, since the vast majority of users will simply stick with the default configuration that they are given. >Dao: These are all OS-independent. Yeah, the only reason we are looking at different tab configurations for each OS right now is that placing the traditional menu bar below the tabs (for instance on XP or Linux) would feel really strange, and clash with the surrounding applications both visually and interactively. Also in general XP users may value consistency with the past over what we believe is a better design. >Actually, I don't understand the second point Giving the user a metaphor to something from the real world: http://upload.wikimedia.org/wikipedia/commons/4/43/43foldersexample.jpg

>just making it customizable could satisfy the users who'd think we're stagnating But wouldn't help us with the tech press who are going to write generalizations based on their first run experience and set a larger narrative that will filter out to general users who repeat universally agreed upon memes and assertions.

This discussion is becoming a little fragmented and off topic and this bug is only a mix of older bugs. The point I see is if this bug is fixed properly you want have UI redyndancy: * Default or option to not have title displayed twice * Only 1 'new tab' button as apposed to the currently situation of 1 customisable one and 1 static one The only other 'real' win as I see it is: * Default or option to have more screen space for content This is clearly not to do with fitting in with the OS, if you remember what IE8 did was stick the address bar above the menu bar and there's been no push to do that on Windows. Either these 3 points are a big enough win for users (logical hierarchy and minuscule situational win on Fitt's law don't seem to stand strong enough for me) or they're not. But almost all of this would of been doable by planning and fixing pre-existing bugs (this one doesn't seem very axiomatic and hence the fragmented discussion).

(In reply to comment #12) > > -Minor efficiency loss due to the mouse having to travel slightly farther > This is the most common argument against tabs on top, and yes, it would be very > helpful to meet it with some hard facts. On the other side, in the default configuration (tabs on bottom with bookmarks toolbar), i have to pay more attention selecting a tab to avoid clicking on bookmarks. With tabs on top i could better use peripheral vision, paying less attention to the "surroundings" (Apart the pathological case of the window's close button. So i feel like the movement is longer but i can pay less attention to it, and so it's faster. This could be seen as a problem of the bookmarks toolbar more than the tab bar, but it somehow exists.

(In reply to comment #18) > (In reply to comment #12) > > > -Minor efficiency loss due to the mouse having to travel slightly farther > > This is the most common argument against tabs on top, and yes, it would be very > > helpful to meet it with some hard facts. > > On the other side, in the default configuration (tabs on bottom with bookmarks > toolbar), i have to pay more attention selecting a tab to avoid clicking on > bookmarks. With tabs on top i could better use peripheral vision, paying less > attention to the "surroundings" (Apart the pathological case of the window's > close button. So i feel like the movement is longer but i can pay less > attention to it, and so it's faster. > This could be seen as a problem of the bookmarks toolbar more than the tab bar, > but it somehow exists. FYI-As someone who has used Firefox dating back to before it was Firefox, I cannot recall ever going to select a tab and clicking on a bookmark instead. As for "hard" data, I use a Microsoft Wheel Mouse Optical with minimal acceleration on WinXP. I adjust the pointer speed to one that allows me to cover the screen in reasonable movements. I prefer no acceleration at all as I have found any form of pointer acceleration totally unintuitive. (When I switched to WinXP from Win2K, the mouse control software stopped offering the UI to turn acceleration off. Go figure.) When I have tried using acceleration, it seems like I have to sneak up on whatever I was going to click or I'd overshoot it. Even since I added the Compact Menu 2 extension which allows me to hide the menu bar, I have yet to have a situation where I mistakenly clicked on a bookmark in the bookmark toolbar when I intended to select a tab. Recently, I installed Ubuntu. It has the mouse set up as a generic Mac OS mouse with only acceleration and sensitivity adjustments. It makes me wonder if many of the issues being discussed about the merits of where the tabs should be located are not more issues of how the mouse or other pointing device is set up. Does the choice of high vs. low or no acceleration have a greater impact on whether the user clicks on the tab than does the choice of tab position being on top or on bottom?

(In reply to comment #19) > FYI-As someone who has used Firefox dating back to before it was Firefox, I > cannot recall ever going to select a tab and clicking on a bookmark instead. indeed, that's because you actually look at the tab bar with attention when selecting a tab. Trying Chrome i've noticed i look less at the tab bar, i recall the position of various open pages and i just move up the pointer and click. I never pointed out that as a "common issue", indeed i also never mis-clicked, but my eyes spend more time on tabs.

A possible solution: For the first build (and minor updates) with relocatable tab bar: 1. Default it to on-top for everyone, but... 2. Have a per-profile first-run notification (or start page) that introduces the user to the option and includes a toggle that immediately show and sets the user's selection. A start page (tab) would likely be better, because it would be less intrusive and users already familiar with the option can casually ignore it. Dismiss the tab once the user chooses to commit the selection. For subsequent major builds: 1. Default to on top for new installations, but maintain the user's setting for upgrades 2. By now there should have been sufficient coverage that the start page (tab) should no longer be needed.

>With tabs on top i could better use peripheral vision, paying less >attention to the "surroundings" (Apart the pathological case of the window's >close button. So i feel like the movement is longer but i can pay less >attention to it, and so it's faster. It's definitely the case that an increased number of targets makes it more difficult for the user to locate a specific target (not necessarily in terms of misclicks, but just in terms of identifying what they want to click on, quantified in milliseconds of cognitive processing time). So when I said a minor efficiency loss, I guess it is fair that that was meant in terms of the physical action of targeting the tab, and we could potentially even make up the difference if we happen to cut down the user's conceptual processing time. Unfortunately, humans are way more complicated than computers so it's hard to know ahead of time which interface is more efficient. (although efficiency is really just one aspect of the overall design, with conceptual complexity and visual design also coming into play). Here are two potential studies we could do to answer the specific efficiency question: 1) Using Test Pilot, we could record a time stamp and screen coordinates when the mouse has transitioned from being in a resting position to now moving. If the user clicks on a tab, we record a second time stamp and coordinates (and if the user clicks on something that isn't a tab, we just throw away the initial data). This will allow us to calculate average distance and time on task for all mouse based tab selections. We can then run the study with both interface to get a sense of the change. Since we are aggregating across a large number of users this allows us to hopefully account for variations like the number of items on the bookmarks toolbar, the user's mouse sensitivity (which as discussed above definitely comes into play), environmental aspects like if the user is in a noisy coffee shop, etc. 2) We could also reach out to NASA Ames to see if they are interested in running another cognitive modeling study for us. This simulates everything and doesn't involve actual users, and the data is based on what are believed to be baseline values for normal human mental and physical abilities. (critics would argue that these values are simply representative of 20-something college students forced to complete cognitive science experiments for extra credit at a number of American universities). Normally this kind of study is done for physical interfaces like the controls of a fighter jet, but NASA previously did a study for us on the positioning of the tab close button: http://people.mozilla.com/~faaborg/files/20070509-CHI2007/p1783.pdf However, I really do expect that if we run these studies the result will be that tabs on top is a less efficient interface (although perhaps only slightly). It would be interesting to finally quantify this, but I'm primarily interested in the design for the reasons beyond pure efficiency, like the cleaner conceptual model and sleeker visual design.

My opinion is that Firefox should not change the existing position of the tabs. The arrangement of toolbars and objects on the toolbars is usually already based on tabs below the toolbars. The majority can't be converted anymore. But for new users that's another story and in that case the best presentation should be offered. Maybe Firefox could do a check on startup if there is an existing profile (e.g. a localstore.rdf file with data) and in that case it should decide to leave the tabs below the toolbars. If there is no localstore data in the profile it is a new configuration and then the tabs should be positioned on top. A great idea would be a set of 3 choices in the Options window: 1. tabs on top 2. tabs under toolbars 3. tabs between page content and statusbar

So long as this **** doesn't effect the design of my private awesome skin then I'm fine with it with power functionality in the menu bar!.. the new FF4.0 style looks ****, tabbar over navigation is just stupid and retarded, when the importance is on the tabs being closer to the page layout, and representing the current tab page ...tabs above navigation is the sort of retarded Google chrome **** design. Navigation/address bar is better above tab buttons, where tab buttons are closer to window content! "* Fix a redundancy in having both a titlebar with page title as well as a tab with the page title" Only a **** moron wouldn't understand that having a window application/document Title in the same fixed position helps with user desktop management and alt-tab.. keeping the title location in a fixed locations helps user navigation. Much like XP, until those **** morons at Microsuck decided that lets **** up the Explorer shell, and have some windows not show a title in a fixed window location properly.. and then more morons like the idiots redesigning whats going to end up being SHITFOX at its current pace of **** added and useless effort going in decided that not allowing users to see a window/app site address in a fixed location... and instead have to look in some other VARYING position was some sort of **** bright idea.. well its **** not you idiots! "* A Fitt's Law win if the window is maximized" Fitts Law FAIL, if window isn't maximized! WHICH IT MOST OFTEN ISN'T YOU PRICKS "* A small vertical space savings allowing more room for content" hey what **** content.. you effing morons are taking away content and functionality.. heck you **** idiots haven't actually done anything to improve content and functionality since like forever.. the majority of content and functionality provided in the browser is by third party developers, adding the power browsing useful features. And reducing toolbar height is not the **** problem.. the problem is in your **** retarded design.. Go **** check Maxthon2 for how a window layout could have been achieved and still allow for a title bar! Aswel as reduced UI space allowing for extra page content height! "* Creates a more streamlined UI" Creates a pathetic piece **** designed for noobtards! And forces any other real theme designed to have to work around defaulty ****! and make heavy changes just to get back to how its already a better setup.

I vote you make the tabs on top change the default AND unchangeable, just for the guy in comment 24...

Go ahead make my day, Firefox 3.6, 3.7 /4.0 have already shown plenty of signs of heading down the **** anyway. The only thing holding this bucket of junk up is the third party developer support in addons anyway. UN-Customizable **** designed for retards like Google Chrome was, for such nooblets like the above poster, will do nothing to keep the real professionals around. I'd sooner head back to Maxthon, they at least have a clue about innovation and providing users with decent browsing features, before its much later ripped off by other browsers.

(In reply to comment #24) (In reply to comment #26) If you actually want the developers to listen to your complaints you should start by not acting immature and then spell out your complaints with examples rather then cursing immaturely and attempting to put people down. Grow up! You need to read the bugzilla etiquette (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) and then take your spam to the newsgroups, like here http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/9e569626887ae703?tvc=2&q=Proposed+Direction

As Kurt suggests discussion over the advantages and disadvantages of the change should really move to the newsgroups. Debating in bugs focused on specific development work limits broader discussion and is less transparent to the community.

(In reply to comment #28) > As Kurt suggests discussion over the advantages and disadvantages of the change > should really move to the newsgroups. Debating in bugs focused on specific > development work limits broader discussion and is less transparent to the > community. Well, I won't answer here for rebellious reason to be contrary to the above, but because discussion here is much more developed than in that link on news groups, and I don't see how to port it there. And my comment is serious, and not the one that caused critics anyway. I think that efficiency should measure Fitt's law against longer traveling of mouse on the one side, and importance (frequency of click) of toolbar items vs tabbar items on the other. So, first question is whether people more quickly click on items positioned directly above content, or at the top of the window (if maximized) And then next question is which items people use more - toolbar or tabbar. And then more important items should be positioned in more prominent place.

users goto click on the tabs way more often than toolbar buttons or even the location bar. completely fcking retarded design, I'll just go suggest notepad++ place the tabbar above those toolbar icons.. I'll just go suggest to a bucket load other developers that document tabs now need to be above TOOLBAR buttons and any other less important ****, because the actual document view and document tabs now must be placed further apart, because retards like Google and Firefox designers think this is better more intelligent design, its hardly intuitive or fluid for any user let alone a power user. I'll just put this down as designed for clueless noobs by noobs. And Google couldn't design anything properly, like their newsgroup -sucks, the simple and dumbed down they can make something the easier for them, its the only reason their search is successful. And just look at the chrome browser ain't nothing good in that. Simplified garbage, much like Firefox 4.0 will be when all menu items get crammed into one button.. that is the kinda **** you see coming out of MSIE and the extra fail is removing a fixed position title window/tab title (+ or any extra info) at the top of the window layout.. only retards could screw up desktop window management and UI layouts this badly, its like a combined effort of megatardation supported by idiots at Apple, Microsuck, Google and now Mozilla, who've really only had the success on the backs of good third party extension developers anyway. Really disappointingly weak changes (they ain't even improvements by a longshot) by now I should be seeing a browser going into supporting a intuitive power features like giving users the ability to pull out videos objects into a seperate window with extra options like Always ontop so users can carry on browsing ie http://forum.maxthon.com/viewthread.php?tid=74749 And more features improvements, not removing things like 'element properties' no no don't IMRPOVE IT.. just remove it for the retards, how dumbed down are things going to get. or many other actually useful browser and feature enhancements.

(In reply to comment #0) > * Gives Firefox a correct UI hierarchy where the controls are tab specific Actually, this is only half true. I think it more adds to inconsistent UI hierarchy than it helps. My argument is that sidebar is in no way Tab related, and it seems that it will appear under tabs in new design. If it is meant to squeeze all panels on open, then this is not the case, but then there is another problem, and that is Fitt's law and position of back button.

Ria Klassen has a really solid idea. Those upgraded to 4.0 should have their minimal customizations intact. As in, Default Strata user made a button move to a specific position or the Bookmarks ToolBar active, the upgrade should have no affect on them other than aesthetics and tabs below the location bar exactly how they remembered it. A mention should be made on the Firefox Upgrade landing page that the tab bar could be repositioned above or below at will. Because the Firefox selling point is all about customization and choice. New Users that are installing Firefox for the first time should get the default layout, which would be tabs above location bar and bookmarks toolbar off. The Landing page once again will take care of communicating that it can be changed if its unsettling. Its a very friendly and thoughtful approach.

(In reply to comment #0) > * Gives Firefox a correct UI hierarchy where the controls are tab specific I thought some more on this... I think that opening new tab with middle click is somewhat weird with tabs on top, but probably not so much that people can't get used to. But opening new tab with alt+enter from location bar, or middle clicking go, or middle clicking bookmark... it is pretty confusing and not proper hierarchy. (In reply to comment #32) > Ria Klassen has a really solid idea. > New Users that are installing Firefox for the first time should get the default > layout, which would be tabs above location bar and bookmarks toolbar off. The > Landing page once again will take care of communicating that it can be changed > if its unsettling. There is no argument for this. If you want to say that some people got used to tabs below, and you shouldn't change that, then it doesn't apply just to Firefox users, but also to IE and Opera users, and why you have right to confuse them more than you confuse Firefox users? (Of course, if that's confusing at all)

The only (In reply to comment #33) > There is no argument for this. If you want to say that some people got used to > tabs below, and you shouldn't change that, then it doesn't apply just to > Firefox users, but also to IE and Opera users, and why you have right to > confuse them more than you confuse Firefox users? (Of course, if that's > confusing at all) I'm sorry. If you're confused, then I invite you to read it again. Its pretty straight forward.

I am sorry, I can only repeat what I said above, and add that tabs below are not customization but default, as there is no way to put them in any other position in Firefox 3.6.

Why not fix bug 347930, which this bug depends on, then run a trial with users trying the alternate positions and submit reports of which works best? Then you will know for sure, instead of spending weeks arguing about what might be, could be, should be, isn't.

Lugging the UI around with each tab *feels* sluggish and bloated and disorienting. This is just one more reason (of the MANY given in this bug) why tabs on top is a bad idea. I have read very few reasons (none convincing) why tabs on top would be better. Another case of personal whim combined with power winning over reason.

There is absolutely no point in discussing where it should go. The only way that we can possibly be sure of this is with usability testing. If we argue about it, we are only wasting each other's time.

(In reply to comment #38) > There is absolutely no point in discussing where it should go. The only way > that we can possibly be sure of this is with usability testing. If we argue > about it, we are only wasting each other's time. And the good thing is that when we get it done, we can always offer the option, even though it may be disabled by default.

I don't think we should bother with UI parity with Microsoft products. They are not known for maintaining UI consistency and nativity within their own products. Mac is a different scenario, but most Windows users never expect consistency between Windows and a 3rd Party UI. Also most people are used to tabs-on-bottom as only Chrome implements to tab-on-top version. So implementing the new version as default for 95% internet users breaks familiarity and is illogical. There doesn't seem to be a big gain in space between the two versions. If I can change to my preferred version without resorting to an addon, I will be definitely happy.

(In reply to comment #40) Opera also has a tabs-on-top UI. Of course (to repeat), there will be an option for tabs-on-top and this will only be the default on Vista/7.

(In reply to comment #41) > tabs-on-top [...] will only be the default on Vista/7. And that default is exactly the problem. There is a thread in news://news.mozilla.com:119/mozilla.dev.apps.firefox (Subject: New Theme/UI Work Initiated) that addresses this issue. It would be great if someone could summarize (via a bullet list) all the disadvantage and advantages of placing the tabs separate from the content (that were brought up in the various comments here) in that discussion thread.

I'd be all for tabs on top if they were presented like a ribbon, with a container coming down from the tab to encapsulate the navigation bar and bookmarks toolbar. At the moment, in all the mockups, it looks messy and rather like it's just an attempt to follow a new standard rather than that it's been a real design goal. If it's given the feel of the Microsoft Office, you somewhat deviate from what Opera and Chrome has done, while sticking to the principles but allowing for real integration of feel and an innovative approach. I'd even go as far as to say you can then have the bookmarks toolbar slide out from the right and 'hover' over the ribbon pushing all the navigation buttons to the left slightly. Or simply have it as another permanent tab like the home tab. The possibilities are endless but the ideas proposed in current mockups are a little off and unimaginative.

Also, using a ribbon would allow for application of personas on a glass based themed, even if there's transparency on the ribbon by default.

(In reply to comment #24) > **** retarded design.. Go **** check Maxthon2 for how a window layout > could have been achieved and still allow for a title bar! Aswel as reduced UI > space allowing for extra page content height! http://blog.blog.zive.cz/files/2010/03/mx3084.png Wana say something intelligent about that?

The purpose of this bug is for design and implementation discussion, please disregard the trolls.

My appologize. But too late, troll has already infected my mail.

Mr. Henky, don't feed the trolls.

What about tabs on the side? Is that still planned? Is there a separate bug for that?

AFAIK, it has never been *planned*

Oh... well, that's disappointing. :(

Aside the fact that there are add-ons for that, most of today's monitors are 16:9, or 16:9. They have plenty of width space, but reduced height space. Whats the point placing them vertical instead of horizontal? Do you want from page to look like cube?

That discussion doesn't belong in this bug.

In regards to the bookmarks toolbar, it's current use is about the quick loading of frequently used sites and with tabs on top, you generally break the hierarchy IMO. Could it not be considered in having them in a panel that drops down over the tab and navigation bar once the mouse is moved to the top of the screen? Or even have the favicons sit beside the app button ala Office 2010 (Save, Print, Undo)?

(In reply to comment #50) > What about tabs on the side? Is that still planned? Is there a separate bug for > that? This is Bug 218280.

After landing this in trunk, could be the next step drawing in titlebar?

I think the next step will be the new style for tabs.

Oh, yeah, I forgot about that.

Comment on attachment 436744 [details] [diff] [review] patch >diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js >+var TabsOnTop = { >+ set enabled(val) { >+ //XXX: Trigger reframe. This is a workaround for bug 555987 and needs to be >+ // removed once that bug is fixed. >+ gNavToolbox.style.MozBoxOrdinalGroup = val ? 2 : 3; Where do 2 and 3 come from? Just arbitrary non-default values? >+ toggle: function () { >+ this.enabled = !this.enabled; >+ this.syncCommand(); >+ }, Makes more sense to put the syncCommand() in the enabled setter, doesn't it? Do you really not need border/margin style changes based on position for windows/linux, as in attachment 432165 [details] [diff] [review]? I only tested this on Mac. Probably wouldn't hurt to get UI-review for the menu items.

Comment on attachment 436744 [details] [diff] [review] patch Oops, I submitted that too early. It looks like this patch doesn't work in my Mac build, I think because the "force a reframe" hack isn't effective.

Actually it doesn't seem to work even after a restart or for new windows, so maybe there's more to it than that. I don't have time to investigate further at the moment.

(In reply to comment #61) > >+ //XXX: Trigger reframe. This is a workaround for bug 555987 and needs to be > >+ // removed once that bug is fixed. > >+ gNavToolbox.style.MozBoxOrdinalGroup = val ? 2 : 3; > > Where do 2 and 3 come from? Just arbitrary non-default values? Yes. > >+ toggle: function () { > >+ this.enabled = !this.enabled; > >+ this.syncCommand(); > >+ }, > > Makes more sense to put the syncCommand() in the enabled setter, doesn't it? Yes. > Do you really not need border/margin style changes based on position for > windows/linux, as in attachment 432165 [details] [diff] [review]? I only tested this on Mac. It's not really needed, and since the tab styling is going to change anyway, I didn't bother.

(In reply to comment #63) > Actually it doesn't seem to work even after a restart or for new windows, so > maybe there's more to it than that. I don't have time to investigate further at > the moment. If you had the earlier patch applied, the 'ordinal' attribute might still be set on TabsToolbar. It will override any -moz-box-ordinal-group setting.

Moved the syncCommand call. Alex, this adds a separator and a "Tabs on top" checkbox at the bottom of the View > Toolbars menu and to the similar toolbar context menu. Is this ok? Doesn't necessarily need to be the final UI.

Comment on attachment 436849 [details] [diff] [review] patch v2 > the 'ordinal' attribute might still be set on TabsToolbar indeed, that was the problem...

Comment on attachment 436849 [details] [diff] [review] patch v2 Ok for now, but we'll likely revisit the UI later.

Very cool to see this land! If I may nitpick, the menu item's label should probably be capitalized ("Tabs On Top"). At least that seems to be the convention for English menu items. Of course feel free to ignore me if this UI is just temporary :)

Very cool indded. Now, only new tabs and we have basic FX4. That is even cooler!

Verified fixed Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100406 Minefield/3.7a4pre (In reply to comment #70) > Very cool to see this land! If I may nitpick, the menu item's label should > probably be capitalized ("Tabs On Top"). At least that seems to be the > convention for English menu items. Of course feel free to ignore me if this UI > is just temporary :) File a new bug but there are two menu options that aren't all capitalized (Help -> Check for Updates, Bookmarks -> Subscribe to This Page)

I'm not sure if "on" counts as a capitalized word in title case. We could really use a contributor who is an actual real life editor :)

(In reply to comment #73) > I'm not sure if "on" counts as a capitalized word in title case. We could > really use a contributor who is an actual real life editor :) You're right, I forgot about title case. Of course the question is which variant of title case to use... I'm not an editor, but it seems to me that menu items capitalize all words except internal articles, prepositions, and conjunctions (cf. http://en.wikipedia.org/wiki/Title_case#Headings_and_publication_titles). That's why it's "Check for Updates", "Subscribe to This Page" and "Open in New Tab" but "Save As…" and "Zoom In" (the preposition isn't internal in the latter). So I'll change my nit to "Tabs on Top". ;)

Maybe I got this wrong, but shouldn't the Tabs bar be under the menu bar? Actually, shouldn't I be able to rearrange the order of the bars?

Rearranging the order of the toolbars is a long standing (existing bug).

I was wondering why it wasn't done this way in the first place. Keybord shortcut would be nice and practical.

(In reply to comment #76) > Rearranging the order of the toolbars is a long standing (existing bug). Not due to be fixed any time soon I take it?

This bug is fixed so please file new bugs for whatever enhancements/changes keep spamming this bug.

(In reply to comment #76) > Rearranging the order of the toolbars is a long standing (existing bug). Does this bug have a number? As it stands the only thing the "tabs on top" feature does is mess up the UI.

(In reply to comment #81) > (In reply to comment #76) > > Rearranging the order of the toolbars is a long standing (existing bug). > > Does this bug have a number? As it stands the only thing the "tabs on top" > feature does is mess up the UI. https://bugzilla.mozilla.org/show_bug.cgi?id=172818

This isn't completely fixed on Mac. After selecting "Tabs on top" from the View menu, tabs did in fact move to the top of the window (yay!). The Tab bar returned to its original position after I clicked the "Minimize Chrome" button in the upper right hand corner of my firefox window twice. I thought the "Tabs on top" menu-item's state would have toggled as well; it still showed that "Tabs on top" was enabled. I considered filing a new bug for this, but this isn't a new bug; the current implementation doesn't cover all the use-cases on Mac.

Please file a new bug anyway; it needs a fix that doesn't have much to do with the fix in this bug. (I think it's something about frame construction and the ordinal attribute.)