The basic idea is for there to be a dedicated "app tab" group (which only appears once you've made your first app tab). Dragging a tab into that group makes it an app tab, dragging it out of the group removes it from being an app tab. App tabs are visible from all groups, and you cannot zoom into the app-tab group(?). A full spec is to follow.

Assigning this bug to myself for creation of a spec.

What happens to tabs spawned from an app tab? Presumably they couldn't live in the app tab group, since they're not app tabs. Maybe each app tab's children get their own tab group, so there's a gmail tab group for all of the tabs spawned from gmail, a twitter tab group, etc.

Right, except visually it'll be pretty odd in that your current tab group might not be the apptab-tab's group, so opening a new tab will switch you to that apptab-tab's group?

Interesting... yes, I guess you would always be in some other group, so maybe the new tabs just go into that group. It is odd that you couldn't go into the app tab group (although I agree you shouldn't be able to)... how do you get into an app tab from TabCandy? I guess you click on it and it takes you into the last group you had open?

Or we go the more prosaic way and show a transparent message explaining how the App Tab group works (and that you can't switch to them from here).

But what if I'm in TabCandy and I want to go to my gmail app tab? What are the steps I need to take? It shouldn't be "click on some other random tab so you can get out of TabCandy and then select the app tab".

Mass moving all Tab Candy bugs from Mozilla Labs to Firefox::Tab Candy. Filter the bugmail spam with "tabcandymassmove".

After using tab candy for a few days, I think just ignoring them in the tab candy view might be sensible. Since they show up in every group, they're sort of outside the sphere of tab candy. They're just omnipresent. Since it doesn't matter what group you switch to to see them, why bother cluttering up the tab candy view with them?

I left this comment in another bug (Bug 587650) which got duped, but I feel pretty strongly about it so I'm going to be a pain and repost it here. "TabCandy and AppTabs are both fantastically useful, but the current interaction between the two makes each less useful to me by a huge amount. The current behaviour is that AppTabs appear in the browser window regardless of which Tab Set I have put that tab in. This means that my Twitter app tab -- which is in my "distractions" tab set (where it belongs) -- appears in my "work" tab set, which means it is just there being a massive distraction. Ideally, I would like to be able to set Twitter as an App Tab in my Distractions tab set and have it only appear when I bring that tab set up. So, App Tabs would be per tab set, not universal." I really would like App Tabs to not be universal, it reduces their usefulness by several orders of magnitude, imo.

Deb, I understand your point of view, however you need to understand the other point of argument. If App Tabs are not universal but located only in the tab group that it was created, it will create a misleading information to the user, as App tab will always be in the left-side of the tab bar, no matter what tab group you choose. Example: Tab Candy have 5 group created by the user. App tab in group 1 only. Group 2,3,4 and 5 all don't have app tab in them. But when user chose group 2,3,4 or 5, he will still end up with App tabs in the tab bar. Maybe an option can solve your problem... By default App tabs are universal, but you can choose to make it per tab set.

(In reply to comment #13) > If App Tabs are not universal but located only in the tab group that it was > created, it will create a misleading information to the user, as App tab will > always be in the left-side of the tab bar, no matter what tab group you choose. That's based on a presumption of the App Tab model which is currently under debate: specifically, should App Tabs persist/be mirrored across all windows, or should they be specific to a window. There's a thread on that, here: http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/70db033456ac7e5c# I'm not sure that it's decided, yet. The two sides of the debate seem, to me, to boil down to one issue: how universally should we present web apps as represented by "app tabs". Deb believes that they should be specific to a specific set of activities, whereas the design posited in this bug indicates that they are universal. Things to consider: - likely dependent on the type of web app (ie: want to be able to get to a music streaming app from anywhere, but might only want my RSS reader to be in a "distraction" set) - likely dependent on user preference (we won't please everyone, here) - needs to build a solid mental model - needs to make sense if/with how we present app tabs in multiple windows

My point is that having App Tabs always on the left hand side of the tab bar is precisely what I don't want. If my Twitter App Tabs is in my "Distractions" tab set, then I only ever want to see that App Tab when I pull up the Distractions tab set. It should not be visible when I am looking at another tab set. If App Tabs are always visible and universal, then they're just not useful anymore, since most of what I use Tab Candy for is to hide some tabs when I'm paying attention to others. If I can't hide App Tabs, then I'll just never be able to use them, which is a shame because they would otherwise be incredibly useful.

Deb: I'm curious, why do you want Twitter to be an app tab at all, then? My mental model of app tabs are "the things I always want open", which currently is my gmail and my zimbra mail. I expect to be able to get to them from anywhere, which is why I've made them app tabs. If you have a tab that you only want to be in one group, why not just put it in that group as a regular tab? With Tab Candy grouping it should be easier to find your tabs since they're grouped with like tabs and not lost in the sea of "all your tabs".

In this specific case, you're talking about the interaction between App Tabs and groups of tabs as created by Tab Candy. I'm not sure we can separate that from the model used when I have N windows open: App Tabs either need to be persistant across all windows, or specific to a window. If specific to a window, it makes a ton of sense for them to be specific to a tab group that is being "focused" in that window using Tab Candy, yes. Personally, I think App Tabs should: - be available when a new profile starts - otherwise be tied to a window - be easily recreated if the window containing them is closed - be given higher frecency for Switch to Tab (Realizing that this is slightly OT for this bug - not sure if there's a better one, though)

App Tabs are for stuff I always want open, but I don't necessarily want to always have visible. For example, I always want to have Gmail and Zimbra open, but one is personal mail (and goes into the "Distractions" tab set) and the other is work mail (which goes into the "Work" tab set). When I'm working on work stuff, I only want my Work tabs visible, and when I take a break or am done for the day, I want to be able to hide my work tabs (including my work mail) and pull up my personal stuff. Likewise for my gaming tabs -- I have a set of App Tabs that I'd like to have for that (two forums, one wiki, and a couple of databases), but I only ever want to see those when I'm actually gaming. They're app tabs for me because I always want them open, unlike other temporary game-related things like quest-lookups and such. So App Tabs for me are for sites I always want to have open because I use them a lot, while regular tabs are for temporary or transitory things. Tab Sets are for organizing those tabs (both permanent or temporary) into groups that I can pull up or hide as needed. I think I treat Tab Sets almost like desktop Spaces -- some spaces always have stuff open in them but they're not always visible.

Is it possible to create a App Tab specific only to a Tab Group? It is an interesting Idea.

Deb - I do see your point, and it is indeed handy to have some tabs always open (universap AppTabs) and some only in a certain tab group. However, I don't think there's a functional distinction between an AppTab and a regular tab in a tab group when it comes to "always open", when you have the browser reload your previous tabs at startup. Essentially, as long as you don't close a tab, it's "always open", no? I'm just worried that making an option for an AppTab to be always available as it is now, or available only to a tab group, will further confuse many users. Plus, if you simply leave a tab open in a tab group, then it is functionally no different than an AppTab in that group. Since the point of an AppTab is to be universally available as opposed to a regular tab, then I think making it possible to set an option on a universal tab to make it un-universal is a lot of extra work, just to get a tab back to being non-universal like it was to begin with :-)

These are some old pictures from http://www.flickr.com/photos/azaraskin/4844251691/

Suggestions down this line would be to only show the apptab list in the group on hover instead of always.

Bug 581736 originally allows showing app tabs from any group from Limi's comments of that the user should't need to actively keep track of which group they're in to remember which has what app tabs. If the user wants to get to an app tab, it's always going to be in the same position nomatter which group is visible.

Perhaps a solution would be to have a special "global" tab set that is available by default. If you create an app tab, you can add it to this tab set to have it appear in all windows. Otherwise app tabs would be specific to the window it's created in.

(In reply to comment #18) > App Tabs are for stuff I always want open, but I don't necessarily want to > always have visible. For example, I always want to have Gmail and Zimbra open, > but one is personal mail (and goes into the "Distractions" tab set) and the > other is work mail (which goes into the "Work" tab set). When I'm working on > work stuff, I only want my Work tabs visible, and when I take a break or am > done for the day, I want to be able to hide my work tabs (including my work > mail) and pull up my personal stuff. Right. This is solved with normal groups. App Tabs are for things that need to *always* be visible, a good example would be Pandora ("oh, I hate that song, I want to skip to the next one"). If something like Twitter is a tab that you only want to be present in certain tab sets, you open them as normal tabs. > Likewise for my gaming tabs -- I have a set of App Tabs that I'd like to have > for that (two forums, one wiki, and a couple of databases), but I only ever > want to see those when I'm actually gaming. So, don't turn them into app tabs. :) > They're app tabs for me because I > always want them open, unlike other temporary game-related things like > quest-lookups and such. That's not the separation we're going for with app tabs. I'm not saying your use case is invalid, but it's not the one we're trying to solve with app tabs. :)

As of Todays current build of Minefield app tabs are not working properly with groups. I think this is either simply a bug or stems from confusion as to how to mix apps and groups. Currently: Apps tabs are persistant through all groups(good) App tabs are associated with either no group or a regular tab group(bad) Clicking on a App tab switches the Active group(the workspace) to the apps current group(or the nogroup group)(very bad) For simplicity I think tabs should simply be ignored in the Groups window for the moment. If we want to add a make tab button and have a area, maybe at the bottom on the window area like a AWN/OSX taskbar you can turn tag tabs into apps with. Most importantly though is to keep Apps from switching my active group, the way it is now I have to choose which feature Id like to use. If anyone has a better paradigm to solve the current issue I'd be interested.

For the record: This is the current specification for app tabs in Tab Candy: http://www.flickr.com/photos/azaraskin/4845263796 That said, we are waiting for the UX team to make a final call (modulo what is technically feasible in Firefox 4 timeframe) on how App Tabs function. Before then, we aren't actually spending any time working on a solution that we might be drastically altered. I can see arguments on both sides of the debate and I lean towards Beltzner's solution where we have two types of App Tabs: (Normal) App Tabs and Universal App Tabs. The former work the way Deb describes, and the later work the available-anywhere way. Other potential names are "pin" tab and "app tab" with all of their included

It would be nice to see the "Universal App Tabs" each get a separate icon on the Windows task bar. That would farther distinguish them from normal and "pinned" tabs and increase the ease of accessing those tabs from outside Firefox. (See bug 582370)

(In reply to comment #28) > That said, we are waiting for the UX team to make a final call (modulo what is > technically feasible in Firefox 4 timeframe) on how App Tabs function. Before > then, we aren't actually spending any time working on a solution that we might > be drastically altered. The decision has been made as far as the UX team is concerned — app tabs should be global, i.e. exist in all windows/sets. I agree that we have to wait until app tabs actually work that way before making the necessary changes to Tab Candy.

re comment 29: I don't think that's going to happen, and I know it's definitely not going to happen in Firefox 4. re comment 30: OK, good to know. The products team (hey that's me!) will take it under advisement! :)

Just a note, in the last Firefox nightly, this works pretty much as described (app tabs have a separate tab group, they appear no matter what group you're in) - except when you switch to an app tab, you end up switching to the app tab group and all your tabs disappear. Which is a little bit annoying :)

re: Bug 589228 though I obviously understand why nothing is implemented until some more decisions are made, I believe a temporary solution is needed right now. Because clicking an App Tab also switches to the group the tab was created in, the usefulness of App Tabs is significantly reduced. After clicking, say, the App Tab for Twitter the user must activate TabCandy again to return to the group he was originally using, thus workflow is disturbed and any time saved by accessing Twitter via an App Tab rather than TabCandy has been rendered moot.

I completely agree currently the users have to choose between using groups or using app tabs since the unwanted effects far out weigh the desired affects. I think the spec from aza's comment is great and don't see why it would be hard to use that for the moment the differences between the daily build and that is very small: This is the current specification for app tabs in Tab Candy: http://www.flickr.com/photos/azaraskin/4845263796 Whats confusing for me is why these issues haven't been worked out until now, the software is beta not alpha. Shouldn't the spec have been decided upon before the switch. (In reply to comment #33) > re: Bug 589228 > > though I obviously understand why nothing is implemented until some more > decisions are made, I believe a temporary solution is needed right now. Because > clicking an App Tab also switches to the group the tab was created in, the > usefulness of App Tabs is significantly reduced. > > After clicking, say, the App Tab for Twitter the user must activate TabCandy > again to return to the group he was originally using, thus workflow is > disturbed and any time saved by accessing Twitter via an App Tab rather than > TabCandy has been rendered moot.

(In reply to comment #34) > Whats confusing for me is why these issues haven't been worked out until now, > the software is beta not alpha. Shouldn't the spec have been decided upon > before the switch. > To be fair to those developer and community members working hard to make Tab Candy and App Tabs workable, I think you should not judge by its label of alpha or beta. App Tabs landed in trunk in Beta 2 and Tab Candy landed in trunk in Beta 4. So it is not possible for them to fix anything in alpha.

(In reply to comment #32) > Just a note, in the last Firefox nightly, this works pretty much as described > (app tabs have a separate tab group, they appear no matter what group you're > in) - except when you switch to an app tab, you end up switching to the app tab > group and all your tabs disappear. Which is a little bit annoying :) Uh? App tabs seem to appear in the first group in panorama view and in every group in browser view. Clicking app tabs sometimes does strange things and after that new tabs often end up in nirvana (in no group). This is totally confusing. Please fix this asap or people will hate the feature (or even worse: make fun of it!)

Just to add another use case for tab groups and app tabs, what I'm currently doing is using app tabs as anchors for tab groups (which works perfectly with the way Firefox currently operates.) For the most part, I have one app tab assigned to each tab group, so that all the tabs spawned from it end up in the same group. For instance, my Google Reader app tab spawns lots of additional tabs which all end up in the time wasting group. This is preferable to Reader-spawned tabs ending up in whatever tab group I happened to have open before I clicked on the Reader app tab. When I want to switch back to my work tabs, there's an app tab for that (gmail, in this case.) Since Ctrl+Tab quickly swaps between the last two tabs open, I haven't found it to be a big issue when clicking an app tab takes me to a different tab group. Ctrl+Tab swaps you right back to the last tab and group (although having some shortcuts to navigate tab groups quickly would also be nice.)

After discussing things deeply with zpao and limi, we've decided that we can't contain "global" App Tabs for Firefox 4. We've updated the design specification for App Tabs accordingly: https://wiki.mozilla.org/Firefox/Projects/App_Tabs This means that App Tabs will only exist in a single window. It is our recommendation that this also should mean that App Tabs should be confined to a single Tab Group in Tab Candy like any other tab. Of course, they can (and perhaps should!) be displayed differently, perhaps as favicons along the top or left side of the group.

I think having app tabs global across groups is critical. If app tabs are in groups and windows then the only thing special about them is that they are smaller and they persist through sessions without question. At that point i would just assume drop app tabs. I don't see why it would be hard to simply exclude them from groups all together for the time being, if you can point out in the code why this is a hard change maybe itll make more sense. Making the interface deal with global apps in the tab candy might be hard but its not necessary for functionality, so I don't see it as a blocker to the spec. What would happen if you just didn't assign them a group and/or designated a global group. I think what is confusing the conversation is other people using it in its current state and trying to form use cases around those. This feature for me personally is worth development time. If someone wrote a patch which made this work like the spec I proposed/basically the original would zpao and limi be ok with that? A link to the trac page with the last changeset related to tabcandy or apps would be useful for me to jump on this tonight. (In reply to comment #39) > After discussing things deeply with zpao and limi, we've decided that we can't > contain "global" App Tabs for Firefox 4. We've updated the design specification > for App Tabs accordingly: > > https://wiki.mozilla.org/Firefox/Projects/App_Tabs > > This means that App Tabs will only exist in a single window. It is our > recommendation that this also should mean that App Tabs should be confined to a > single Tab Group in Tab Candy like any other tab. Of course, they can (and > perhaps should!) be displayed differently, perhaps as favicons along the top or > left side of the group.

I agree that confining an app tab to a specific tab group makes app tabs almost pointless - it's effectively no different than simply leaving the tab open. Making a global tab, but then confining it to a non-global group, is moving backwards and makes the entire feature practically moot. Currently, selecting an app tab automatically switches to that tab group. This is convenient and useful. Working the other way around means that to find an app tab, I need to open the tab groups page, find the correct tab group, and then click on it. That takes more time, effort, and additional clicks over having a tab always pinned to the left of the tab strip, which (I thought) was the whole point of app tabs. From a UI standpoint, I strongly believe that changing the spec of an app tab to become essentially a normal tab defeats the entire original purpose and use as people have come to expect and appreciate it. It's a step backwards and doesn't make sense from a user perspective. 99% of all Firefox users are going to be non-technical people, and I'm picturing a developer trying to explain to a user how cool and useful app tabs are, when as far as the user can see or experience, the only cosmetic difference is a narrower tab, and the only functional difference is - well, what exactly is it again?? It restores automatically all the time - just like every other non-app tab. It seems to me that after all the effort that went into designing app tabs, to remove 90% of their functionality and deliver what boils down to a "skinny tab" is a sad move. It's like something Microsoft would do when releasing a new OS, with most of the promised features cut at the last minute.

Your opinions have been made clear. Put plainly, App Tabs cannot be implemented as global across windows, and so it simply does not make sense to make them global across groups in Tab Candy. It would pollute the mental model. I suggest that unless additional information or design proposals can be brought to bear, we refrain from comments that are purely advocacy and allow the Tab Candy team to make a decision.

My apologies. I was mostly looking for a explanation as to why app tabs would be hard to implement from a programmatic perspective. I agree with Adam, if we were to make app tabs simply skinny tabs, I say the whole app tabs idea should be dropped but i don't want to belabor that point. App tabs not being able to be implemented across windows is a good reason not to do it, i agree it pollutes the mental model, although i think not having access to other tab groups for another window is also problematic, I'd rather all windows share tab groups so that you could open a new window and then pick a pre-existing tab group to be your new window. It seems that currently the tab candy frame work has many intuition problems. I can guess at some reasons why 2 windows wouldn't place nice in terms of sharing groups or app tabs, but I wouldn't mind being told what those are explicately. Either way it seems like for these features to really be worth it you will need to possibly expand the connections between newly opened windows. Otherwise I fear that it will fail at exciting end-users or even worse confuse them. Ultimately these features might have been tacked on too late in development. (In reply to comment #42) > Your opinions have been made clear. Put plainly, App Tabs cannot be implemented > as global across windows, and so it simply does not make sense to make them > global across groups in Tab Candy. It would pollute the mental model. > > I suggest that unless additional information or design proposals can be brought > to bear, we refrain from comments that are purely advocacy and allow the Tab > Candy team to make a decision.

Here's a search result for issues reported by users around "app tabs panorama": http://input.mozilla.com/en-US/search/?product=firefox&sentiment=sad&locale=en-US&date_end=&date_start=&version=&q=app+tab+panorama

Thanks Aakash. That is sad indeed! That said, now that we have a full specification for what App Tabs mean in Firefox 4 <https://wiki.mozilla.org/Firefox/Projects/App_Tabs> I'll be updating the spec <http://www.flickr.com/photos/azaraskin/4845263796> and we'll begin implementation soon.

(In reply to comment #41) > I agree that confining an app tab to a specific tab group makes app tabs almost > pointless - it's effectively no different than simply leaving the tab open. > Making a global tab, but then confining it to a non-global group, is moving > backwards and makes the entire feature practically moot. That depends on how you actually use them. I'm currently using the extension faviconize tab which provides similar (but not identical) behavior to app tabs. Combined with protecting the tab from closing (another extension) i simply use them as permanent bookmarks for things like -forums where i'm an administrator -news sites -status pages from servers -webcomics which i read frequently Overall i have over 270 tabs open, about 40 of them are permanent tabs, others are tabs i have spawned from those permanent tabs or visited through other means. Reducing a tab to its favicon + protecting it provides a starting-point for browsing and spawning new tabs into a tab group related to the "app tab" while visually distinguishing it. Having a "news" tabgroup open with reduced news (index) sites and spawning individual news stories from them into new tabs makes sense. Having 5 news sites open everywhere doesn't make sense. Having gmail open in one apptab and spawning individual mails or reply tabs from it makes sense, having gmail among dozens of other app tabs taking up half of the tab bar in every single tab group doesn't make sense. For a light "app-user" it might be plausible to have his 2-3 app tabs everywhere. But if you're a heavy user then you might end up with so many "apps" that having them visible everywhere defeats the purpose of having tab groups in the first place. And tab groups are most important to those of us who are heavy tab users, not those who only open 2-3 at a time anyway.

Here is the updated specification for non-universal app-tabs. http://www.flickr.com/photos/azaraskin/4946904112/

Aza, is it possible to introduce the Make into App Tab option in Panorama itself? I filed bug 588032, you should see it and Wontfix it if its proposed functions are deemed pointless or Set Milestone to "Future" if it is impossible to implement in this current stage.

Ehsan, have you started work on this? Assuming you haven't, I'm taking a whack at it.

First stab at app tab support.

To be frank, I was shocked as I began reading here that app tabs might not be universal among tab groups. App tabs being window-specific is not a big loss at this point as windows are a clear delineation to all computer users, so I would not expect it to be a jarring experience to discover that their app tabs are not universal among windows. This may disappoint some users, and it may be the expected behavior for others. However, it will not severely limit app tabs for most users. Some users (those who do not use multiple windows, like me) may not even notice the limitation. As I am seeing it, the story becomes entirely different when it comes to app tabs being/not being universal among tab groups. First of all, I notice two major types of Panorama users: A) User who dedicates a tab group to a task tied to a specific app tab. For example, one of this user's app tabs might be Google Reader, and as they click links in Google Reader they create a sort of queue of pages to read all contained in this app tab's tab group. This user tends to use app tabs more liberally and would prefer app tabs to be confined to their tab group so their tasks don't spill over into each other. Refer to comments 12 and 48 for specific cases. B) User who wants to dedicate prominent primary UI space to a handful of commonly-used pages/web-apps to facilitate switching to and from those apps quickly. Since many are web apps such as web mail, Pandora, etcetera, they are used more throughout the day than other pages and the user (generally) follows far fewer external links than with a regular page. This user may or may not also use app tabs similarly to user A. I do not want this simply to be an advocacy comment, as Beltzner put it. I am not providing any new hard data or design proposals or anything, but the gravity of this decision compels me to attempt to thoroughly present the case for group-universal app tabs, even if we cannot have window-universal app tabs for Firefox 4. I have been reading comments on Bugzilla for years and have gained an appreciation for the process that goes on here, but I have never felt strongly enough about something to create an account and comment until now. So here are the reasons I believe it would be a failure to make app tabs non-group-universal: 1) User case A is little more than "pinned tabs" (even with chromeless app-tabs), and is easily accomplished today using the faviconize extension, as demonstrated by The 8472 (comment 48). However, user case B is significant added functionality that (from my limited understanding of Firefox source) would not be nearly as easily accomplished by an extension author. Pinned tabs are not a new idea. We have an opportunity with app tabs to introduce a staggeringly useful and new feature, and if we are not going to take that opportunity by supporting use case B and making app tabs group-universal, I do not think it should be done half-way by a simple pinned-tab implementation while calling it something new and innovative. I would advocate rather dropping the feature, as I do not see it as a compelling advancement without being group-universal. If it isn't dropped, it should certainly be renamed to "pinned tabs" to better reflect the feature's true capabilities and to save face. 2) From my reading through a few pages of the search Aakash linked to (comment 46), use case B seems to be more common, or is more of a jarring experience, prompting more feedback (my reason 3). 3) If a person is an 'A-user', I would expect they are less likely to be confused by the behavior in case B than a 'B-user' would be by the behavior in case A. For a B-user, case A may result in "Where did my app tab go?", and the user subsequently re-creating their app tab in each group until they realize that app tabs are group-specific. The user may give up before they figure out how it works, or they may assume it is broken. This results in a lack of confidence in the feature and in Firefox, and puts us in a poor position to later switch to a fully-universal (window and group) app tab implementation (the ideal solution), as the user may be less inclined to experiment with future implementations of the feature. ) For an A-user, the behavior in case B may not be what they initially expected, but after they create an app tab and switch groups they should have little to no trouble realizing that app tabs are group-universal. There may be a moment of confusion as they realize that the feature doesn't work as they originally expected, but there won't likely be any question as to what has happened. This builds confidence in the feature/Firefox and sets us up for future improvements such as fully-universal app tabs and possibly pinned tabs (which, if implemented, would serve both use case A and B). If we go with B, group-universal app tabs, we're adding an annoyance to A-users. However, they can accomplish what they were expecting using an extension (faviconize). If we go with A, we are potentially confusing B-users who may not understand how it works and may assume it is broken, and there is currently no way for them to accomplish what they expected the behavior to be. I understand that the mental model of having app tabs window-specific but group-universal isn't perfect, but I don't think it is a shambles either. I hope you agree. Excuse me for being long-winded. I have trouble communicating ideas fully in few words. :)

unsetting tm. that's set when the patch lands in that release. yeah, unintuitive use of "target", i know.

Comment on attachment 472501 [details] [diff] [review] wip1 >+ >+ // ___ app tabs >+ this.$appTabTray = iQ("<div/>") remote extra whitespace also, please elaborate in your comments - summarize what's actually happening. put yourself in the shoes of someone who's never looked at this code, but is trying to fix a bug, or add a feature. eg: // populate app tab tray with this window's pinned tabs is far more useful than // __ app tabs >+ let icon = tab.image || "chrome://mozapps/skin/places/defaultFavicon.png"; this is used in several places now iirc. maybe move it to Utils.defaultFaviconURL? >@@ -295,25 +320,25 @@ let GroupItem = function GroupItem(listO > window.GroupItem.prototype = Utils.extend(new Item(), new Subscribable(), { > // ---------- > // Variable: defaultName > // The prompt text for the title field. > defaultName: "Name this tab groupâ¦", not related to this patch, but please file a bug asap to get this localized. we're hitting string freeze in a few days. > // ----------- > // Function: setActiveTab >- // Sets the active <TabItem> for this groupItem >+ // Sets the active <TabItem> for this groupItem; can be null. document why it can be null, what the use-case is, and what it actually does when tab is null. > // ----------- > // Function: getActiveTab >- // Gets the active <TabItem> for this groupItem >+ // Gets the active <TabItem> for this groupItem; can be null. document under what circumstances is there no active tab >+ // Sets active TabItem and GroupItem, and updates tab bar appopriately. >+ // Either tabItem or groupItem can be null. If groupItem is null, uses >+ // tabItem's parent. why is groupItem needed then? can't you always just use tabItem's parent? > // ---------- > // Function: link > // Takes in a xul:tab. document what it actually *does* > // ---------- > // Function: unlink > // Takes in a xul:tab. ditto > // ---------- >+ // Selects the given xul:tab in the browser. >+ goToTab: function(tab) { document what "tab" is. xul tab? TabItem? >+ // If it's not focused, the onFocus lsitener would handle it. nit: spelling

To do before landing: * Needs test * With this patch, it's now possible for a xul:tab to not have a .tabItem; make sure this works throughout the code * Address dietrich's comments above * If there are app tabs, squish down the group's content area, so its children don't overlap the app tabs After landing: * Sometimes when you go into the tab, the tab bar isn't set up properly for the group you wanted * Deal with when app tabs are opened/closed. * Deal with when app tabs are pinned/unpinned * Use the correct icon; if the icon isn't ready right at first, watch for the change * If you use "exit" from the Panorama UI (such as hitting the escape key), and the last tab you had been on was an app tab, it should go there (with the group you had been using)

(In reply to comment #54) > unsetting tm. that's set when the patch lands in that release. yeah, > unintuitive use of "target", i know. Ok. I've created bug 594094 to track the items we're wanting to land in b6.

(In reply to comment #53) Ethan, thanks for taking the time to sign-up and give such a thorough analysis of the situation. I'd add a final thought to your list on why app-tabs should be universal. It is the UX team's design goal to eventually have app-tabs be universal across windows and so we shouldn't intentionally break that future mental model when we we can go either way now. To be clear, we are moving back to the model proposed here (http://www.flickr.com/photos/azaraskin/4845263796/) where every app-tab is shown in every group. This has the benefit of (besides the points above) being easier to implement as well as been advocated by Ian for a while.

(In reply to comment #55) > remote extra whitespace I assume you're asking me to remove trailing white space? My editor does not do this automatically, but I've done so now. > also, please elaborate in your comments - summarize what's actually happening. > put yourself in the shoes of someone who's never looked at this code, but is > trying to fix a bug, or add a feature. eg: Done. > this is used in several places now iirc. maybe move it to > Utils.defaultFaviconURL? Done. > not related to this patch, but please file a bug asap to get this localized. > we're hitting string freeze in a few days. Thanks for the nudge. https://bugzilla.mozilla.org/show_bug.cgi?id=586685#c35 > document why it can be null, what the use-case is, and what it actually does > when tab is null. GroupItems can have as few as zero children, so it has to be possible for the selected child to be null. Added a note to this effect. > >+ // Sets active TabItem and GroupItem, and updates tab bar appopriately. > >+ // Either tabItem or groupItem can be null. If groupItem is null, uses > >+ // tabItem's parent. > > why is groupItem needed then? can't you always just use tabItem's parent? Done. > > // Function: link > > document what it actually *does* Done. > > // Function: unlink > > ditto Done. > >+ // Selects the given xul:tab in the browser. > >+ goToTab: function(tab) { > > document what "tab" is. xul tab? TabItem? I've updated the variable name to make it clear. > >+ // If it's not focused, the onFocus lsitener would handle it. > > nit: spelling Done. Patch still in progress.

(In reply to comment #59) > (In reply to comment #55) > > remote extra whitespace > > I assume you're asking me to remove trailing white space? My editor does not do > this automatically, but I've done so now. What editor do you use? You can usually use a regex like \s+$ to find them...

Aza, so will it be possible to implement group specific App Tabs in the future? I see the benefits of Universal App Tab across Tab Groups but Tab Group specific will be useful in some situation for various users(example: students doing project who only want to see app tab in that group but not the app tab in other groups. ) Filed bug 588058

(In reply to comment #58) That's good to hear, Aza. I might have embarrassed myself by my reactionary and "thorough" (read, unreasonably long) comment as it seems to have been unnecessary. I'm just pleased that app tabs are going to end up adding some useful functionality.

(In reply to comment #60) > What editor do you use? You can usually use a regex like \s+$ to find them... I use Coda. I've got a plugin that will strip trailing whitespace, but it doesn't do it automatically, and I don't always remember.

I wonder if anyone has ever made a commit-hook bot for Bugzilla that can automatically look at the patch and highlight standard errors that can be found via simple regexps...

+ Addressed dietrich's comments + Moved app tab button creation in GroupItem into its own routine + Adjusting GroupItem children area for app tab buttons + Added a guard to GroupItems.moveTabToGroupItem, so it would have no effect on app tabs + Added test I think this is ready to go, pending review, and the results of the try build I've just fired off.

Just updated the patch for the latest mozilla-central (there had been some bit rot).

Comment on attachment 473277 [details] [diff] [review] patch v2 > // Function: setActiveTab >- // Sets the active <TabItem> for this groupItem >+ // Sets the active <TabItem> for this groupItem; can be null, for instance >+ // if there are no children. Are there instances where there's no active tab, even though we have children? > getContentBounds: function GroupItem_getContentBounds() { > var box = this.getBounds(); > var titleHeight = this.$titlebar.height(); > box.top += titleHeight; > box.height -= titleHeight; > >+ box.width -= this.$appTabTray.width(); >+ This means we should hit every GroupItem's .arrange() method when we add the first app tab or unpin the last? >+ // Adds the given xul:tab as an app tab in this group's apptab tray >+ addAppTab: function GroupItem_addAppTab(xulTab) { >+ let self = this; >+ >+ this.$appTabTray.css({width: 20}); Please make this themeable, for example by controlling the width (0 or 20) by adding or removing an "empty" class, then adding something like the following to the platform css: .appTabTray { width: 20px; } .appTabTray.empty { width: 0px; } >+ let icon = xulTab.image || Utils.defaultFaviconURL; >+ let $appTab = iQ("<img>") >+ .attr("src", icon) >+ .data("xulTab", xulTab) >+ .appendTo(this.$appTabTray) >+ .click(function(event) { >+ if (Utils.isRightClick(event)) >+ return; >+ >+ GroupItems.updateActiveGroupItemAndTabBar(null, self); >+ UI.goToTab(iQ(this).data("xulTab")); >+ }); >+ }, >+ >+ // ---------- >+ // Sets active TabItem and GroupItem, and updates tab bar appopriately. spelling > // ---------- > // Function: link >- // Takes in a xul:tab. >+ // Takes in a xul:tab, creates a TabItem for it and adds it to the scene. > link: function TabItems_link(tab){ > try { > Utils.assertThrow(tab, "tab"); > Utils.assertThrow(!tab.tabItem, "shouldn't already be linked"); >- new TabItem(tab); // sets tab.tabItem to itself >+ if (!tab.pinned) >+ new TabItem(tab); // sets tab.tabItem to itself > } catch(e) { > Utils.log(e); > } > }, Should we ever call link() on tabs which are pinned? If not, add assert if we are trying to link a tab which is pinned. > unlink: function TabItems_unlink(tab) { > try { > Utils.assertThrow(tab, "tab"); >- Utils.assertThrow(tab.tabItem, "should already be linked"); >+ >+ // Check to see if it's already been unlinked, for instance because >+ // it's an app tab, or because of the "undo close group" waiting period. >+ if (!tab.tabItem) >+ return; Similarly here, if we shouldn't be unlinking app tabs ever, keep the assert. >+++ b/browser/base/content/tabview/tabview.css >+/* Groups >+----------------------------------*/ >+ >+.groupItem { >+ position: absolute; >+} >+ >+.appTabTray { >+ position: absolute; >+ top: 34px; >+ right: 1px; >+ cursor: pointer; >+} It's not DRY, we know, but please move the .appTabTray styling (except the absolute) to each platform's CSS. Also, should the entire tray has cursor: pointer, or just the app tabs in it? >+function onTabViewWindowLoaded() { >+ window.removeEventListener("tabviewshown", onTabViewWindowLoaded, false); >+ ok(TabView.isVisible(), "Tab View is visible"); >+ >+ let contentWindow = document.getElementById("tab-view").contentWindow; >+ >+ // create an app tab >+ let appXulTab = gBrowser.loadOneTab("about:blank"); >+ gBrowser.pinTab(appXulTab); >+ >+ // Create a group >+ let box = new contentWindow.Rect(0, 0, 100, 100); Try Rect(20, 20, 180, 180) or so, so it doesn't have to push itself around on creation. >+ // find app tab in group and hit it >+ let onTabViewHidden = function() { >+ window.removeEventListener("tabviewhidden", onTabViewHidden, false); >+ ok(!TabView.isVisible(), "Tab View is hidden because we clicked on the app tab"); >+ gBrowser.removeTab(appXulTab); >+ finish(); What exactly is the expected state at this point? Should we be back at the original tab? Or did our group just become empty so the group item closes and we go back to tabview? Whatever the expected state here is, check for it before finishing and leaving. Also along these lines, please close the groupItem created in the test before finishing. GENERAL FEEDBACK: I ran into a number of interaction bugs while using this patch: 1. The first time I tried it out, when I clicked on an app tab, it would take me to the group that that app tab was created in. 2. New app tabs only show up on newly created groups. 3. App tab button icons don't get updated after startup/creation. 4. When an tab becomes pinned, its tabitem doesn't disappear... is that part of the spec? 5. When an app tab is unpinned, it isn't (at least visually) added to the group we did this in, so in the tab view it doesn't show up anywhere as a tab. Its app tab button stays in app tab trays, though creating a new group item shows that it should not be there. It may be worth writing some of these scenarios up in the test first before continuing dev. Perhaps these issues warrant their own bugs and can be fleshed out post-b6, however.

One more: >+ let $appTab = iQ("<img>") >+ .attr("src", icon) >+ .data("xulTab", xulTab) >+ .appendTo(this.$appTabTray) We need styling for .appTabTray img (or equivalent) to ensure that the imgs stay the size we expect them to, in case some site has a huge favicon?

(In reply to comment #67) > Are there instances where there's no active tab, even though we have children? There were, but now I've fixed it so that there are not, and updated the comment. > This means we should hit every GroupItem's .arrange() method when we add the > first app tab or unpin the last? Done. > Please make this themeable, for example by controlling the width (0 or 20) by > adding or removing an "empty" class, then adding something like the following > to the platform css: I'm now basing this on the app tab icon size. > >+ // Sets active TabItem and GroupItem, and updates tab bar appopriately. > > spelling Done. > Should we ever call link() on tabs which are pinned? If not, add assert if we > are trying to link a tab which is pinned. Done. > Similarly here, if we shouldn't be unlinking app tabs ever, keep the assert. Done. > It's not DRY, we know, but please move the .appTabTray styling (except the > absolute) to each platform's CSS. I just don't know what's structural and what's not. Done. > Also, should the entire tray has cursor: pointer, or just the app tabs in it? Done. > Try Rect(20, 20, 180, 180) or so, so it doesn't have to push itself around on > creation. Done. > What exactly is the expected state at this point? Should we be back at the > original tab? Or did our group just become empty so the group item closes and > we go back to tabview? Whatever the expected state here is, check for it before > finishing and leaving. Done. > Also along these lines, please close the groupItem created in the test before > finishing. Done. > GENERAL FEEDBACK: I ran into a number of interaction bugs while using this > patch: > 1. The first time I tried it out, when I clicked on an app tab, it would take > me to the group that that app tab was created in. > 2. New app tabs only show up on newly created groups. > 3. App tab button icons don't get updated after startup/creation. > 4. When an tab becomes pinned, its tabitem doesn't disappear... is that part of > the spec? > 5. When an app tab is unpinned, it isn't (at least visually) added to the group > we did this in, so in the tab view it doesn't show up anywhere as a tab. Its > app tab button stays in app tab trays, though creating a new group item shows > that it should not be there. > > It may be worth writing some of these scenarios up in the test first before > continuing dev. Perhaps these issues warrant their own bugs and can be fleshed > out post-b6, however. All of these items need to be addressed post-landing, or this feature will miss feature freeze; I'll write follow-ups for them today. > We need styling for .appTabTray img (or equivalent) to ensure that the imgs > stay the size we expect them to, in case some site has a huge favicon? Excellent point; done.

ready to land, pending results of try build

Adding my username to the patch.

Passed try

My TODO items above, and mitcho's general comments are all addresse with these follow-up bugs: bug 595371 bug 595076 bug 593871 bug 595374 bug 595379

Judging from your correspondence. Discussion about the fact whether the app-tab part of a group of tabs or not. Dividing them into 2 groups: A) Attached Tabs - global, that is always present on the tab bar. It turns out that they both would be members of each group. B) Attached tabs exist only within their group. That is, in one group may be attached to one tab to another - other. My version https: / / bugzilla.mozilla.org / show_bug.cgi? Id = 595869 Combines the two groups. As such, there is one, a separate group, not deleted. And when you create app-tab it is saved in this group. And people from group A are satisfied. But there are people from group B and he wanted to secure for a certain app-tab group or a group, he throws in their group want him to app-tab.

Just my two cents - I started using Tab Candy with - I think it was - 4.03b? I was very disappointed to see App Tabs implemented globally in Minefield 4.0b6pre. I find Tab Candy to be brilliant in the sense that it essentially creates order in what was once a "browsing the web" experience, and now is more of a "using web application" based experience. A tab group for me represents a place where several related web applications are grouped. App tabs makes that connection "permanent" as those applications are pinned to the tab group (take less space in the tab bar, are harder to close, etc). The tab group can contain several more tabs which aren't permanent (which are what remains of the browsing experience). Making App Tabs global is a step backwards in the sense that the app tabs no longer have context, and essentially that limits the user to choosing a small number of permanent applications, which is conceptually the same as old-style "browser applications" such as a music player or a search toolbar. That leaves the majority of web applications in each tab just as volatile as the "browsing" windows, which makes the entire tab group less cohesive and the entire concept of tab candy less appealing. I really hope this decision will be reversed in the future, or at the very least configurable.

verified with recent builds of minefield

(In reply to comment #77) I fully agree with you - using panorama I can browse using different contexts - and each of those contexts should have a different set of apptabs imo - please make it at least configurable...