Closed Bug 587273 Opened 14 years ago Closed 12 years ago

Add Option to disable Tab Groups (Panorama)

Categories

(Firefox Graveyard :: Panorama, enhancement)

Product:
Firefox Graveyard
Component:
Panorama
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: divjot94, Unassigned)

References

Details

(Whiteboard: READ COMMENT 25 BEFORE COMMENTING, [gems 58])

Attachments

(1 file)

Allows conditional in/exclusion of Tab Candy at compile time
27.24 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b4pre) Gecko/20100813 Firefox/3.9
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b4pre) Gecko/20100813 Firefox/3.9

Self explanatory 

There must be an option to disable it 


Reproducible: Always
Summary: Add option to disable TabCandy(TabSets)? → Add option to disable TabCandy(TabSets)
At least provide an option to change the keyboard shortcut in use. Alt-Space is the (well, my) shortcut for non-breakable spaces in NeoOffice. I do now a lot of texting online and still use this shortcut so that now each non-breakable space open the TabCandy window.
(In reply to comment #1)
> At least provide an option to change the keyboard shortcut in use. Alt-Space is
> the (well, my) shortcut for non-breakable spaces in NeoOffice. I do now a lot
> of texting online and still use this shortcut so that now each non-breakable
> space open the TabCandy window.

That should probably be a separate bug.

As for this bug there would have to be a way to allow users to disable it without affecting discoverabiltity (as was suggested for the option to disable Sync). If this cannot be achieved then this should probably be wontfixed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #2)
> If this cannot be achieved then this should probably be wontfixed.

Well, there's no excuse: there's plenty of Space left in the Option's "Tabs" Tab.
Severity: normal → enhancement
OS: Windows 7 → All
Hardware: x86 → All
Summary: Add option to disable TabCandy(TabSets) → Add Option to disable TabCandy (TabSets)
(In reply to comment #3)
> (In reply to comment #2)
> > If this cannot be achieved then this should probably be wontfixed.
> 
> Well, there's no excuse: there's plenty of Space left in the Option's "Tabs"
> Tab.

If it'll affect discoverability of the feature then the feature is pretty worthless so no - that is a good enough reason.

Mike already stated in bug 586985:
> We generally don't have "hide all existence of this feature" prefs... what's
the rationale here?

The same question will be asked here. There will need to be some sort of first-run experience where the feature is explained and the users are given the choice to enable it or not.
> That should probably be a separate bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=587505
If the feature is enabled by default, I do not see how a preference to disable it would adversely affect discoverability.

The user would have to acknowledge that the feature exists, decide they don't want it, and go through the effort of disabling it. It would seem that they discovered it perfectly fine.
Yes, this should be an addon. Enough with the feature creep please. FF is supposed to be a lightweight+extensible browser.
(In reply to comment #7)
> Yes, this should be an addon. Enough with the feature creep please. FF is
> supposed to be a lightweight+extensible browser.

Without innovation then browsers wouldn't be where they are today. Having looked through the news articles about this feature - the comments and articles were overwhelmingly positive, suggesting people do want and need this feature.

This isn't a place to discuss if this SHOULD be a feature since it now is - this is to discuss if and how an option to disable it should be implemented, please keep discussions about anything else, elsewhere. Thanks.
Blocks: 585689
> The same question will be asked here.

And I give the same answer as I gave there: when the feature was being developed as an Add-on this functionality was available, now it's not.  Why should my browser get less flexible just because the feature is now part of the build?

It's even more important in this case because it's easy to accidentally activate the thing with the keyboard shortcut.
The "it was an extension and now it's not" isn't really a valid argument. It was an extension because it was a proof-of-concept/work-in-progress. Being an extension also made it easier to develop and test. AFAIK the original intention was to be integrated into the browser.


I think the real issue at hand is that, unlike Sync, TabCandy has an overhead even when not being "used". Unless the goal is to have a near-zero overhead by release time, I would definitely lobby for a way to disable it. For a feature I'm likely never to use (so far, I find multiple windows easier to use/manage), I'd like to see it act like it's not even there.

Another problem that I have is from the view of a nightly tester. Often when major features land (IPC, HTML5 parser, hardware acceleration, etc), it is pref'd off by default while it's still worked on. I would have liked to have seen that with TabCanndy as well. Even if this was a feature I'd want to use, I'd probably keep it disabled due to annoyances/bugs. For example, higher memory usage (maybe a leak), delay/lag when begin scrolling/clicking links/navigation, tabs randomly being un/re-grouped, not being able to open as many tabs before lagging....

Also, disabling TabCandy doesn't necessarily mean hiding the menu/toolbar items. They could just be disabled.
> The "it was an extension and now it's not" isn't really a valid argument.

I disagree.  The only reason I use Firefox is because of the flexibility the extensions mechanism allows, if everything is just going to get built in then the 'flexibility feature' is being lost, though not in one easily definable moment but in a series of little, each apparently reasonable, steps.

Is there any reason why this needs to be built into the browser at all, what benefits does that have over the extension?  You already listed several advantages of extensions over built in for development.  Why can't we just have a standard set of extensions shipped with the browser then users can disable or remove the ones they don't want?

I don't understand this philosophy of building a load of stuff into the browser that can't be removed unless I go to the bother of setting up a whole build environment.
(In reply to comment #11)
> I think the real issue at hand is that, unlike Sync, TabCandy has an overhead
> even when not being "used".
Evidence? Where are you noticing an overhead?
(From Comment #12)
> For example, higher memory usage (maybe a leak), delay/lag when
> begin scrolling/clicking links/navigation... not being able to
> open as many tabs before lagging....

Obviously, some of that is bugs, but not necessairally all.

Plus, the groups & thumbnails appear to be kept up to date while you're browsing. There has to be a certain amount of overhead to that.
If turning off Tab Candy can reduce Firefox's usage of system resources(like Memory), this option would definitely worth it. This would allow low-end Windows/Mac OS X/Linux/Mobile systems to use Firefox more efficiently. 

But the question is will Tab Candy actually cause Firefox to use more system resources? I assume that it will, if users use it. But will it consume system resources just by being there in the background? 



(In reply to comment #4)
> 
> The same question will be asked here. There will need to be some sort of
> first-run experience where the feature is explained and the users are given the
> choice to enable it or not.

I think Users should have some form of tutorial with Tab Candy in the Final release of Firefox 4. Tutorial can be in the form of video or flash based animation teaching users how to use Tab Candy, that way they can get a good first-run experience.
(In reply to comment #13)
> (In reply to comment #11)
> > I think the real issue at hand is that, unlike Sync, TabCandy has an overhead
> > even when not being "used".
> Evidence? Where are you noticing an overhead?

I've noticed that the tabview iframe loads when hovering over the "Move to Group" item in the tab context menu.
(In reply to comment #11)
> so far, I find multiple windows easier to use/manage

precisely, and I suspect most people will weigh the benefits vs the footprint and come to the same conclusion. It's a very redundant feature that shouldn't be part of the browser. 

Personally I wouldn't even give people a first-run experience, just don't include it even as an included addon. Leave it as a recommended one.
Re: comment #11 and comment #17:
Matthew and/or Graham, could you perhaps start a discussion about his on the dev-apps-firefox forum/mailing list?
https://lists.mozilla.org/listinfo/dev-apps-firefox
I'm pretty sure you'll get more and better responses there (and you seem to have given some good arguments against TabCandy, which is a good reason to start a discussion there).
Ok, just making note that I posted to the list. You can see it here:
http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/2b4782935456910f#
(In reply to comment #16)
> I've noticed that the tabview iframe loads when hovering over the "Move to
> Group" item in the tab context menu.
That sounds like it wouldn't be hard to fix.  Can you please file a bug on that?
I just pressed a key sequence that I have no idea what it was and suddenly I have this activated with no apparent way to back out of it. Because of this and the possibility of losing stuff I don't want to lose, I want to be able to disable this completely so I don't get screwed from unintentionally activating it. I do not have the button on my tool bar either. Please add a pref to disable this as soon as possible. Thanks.
Adding Aza + Mike for comment.
No longer blocks: 588721
"TabCandy/Monster" killing my browser performance completely (rendering is slow especially on slow linux machine)...  and when I accidentally pressing Ctrl+Space, then it is similar to Dead-Firefox state.... only killall -9 helps.

I see this feature is not even alpha state (by performance reason) and we must have option to disable it.
also I would like to disable it for all linux platforms where HW acceleration in XRender is not detected.
I just got quite upset by this tabzilla feature, so was about to file a bug,
but found this one. I find this feature extremely annoying to the end that I
will have to switch to a stable firefox, because it's so much more usable than
this nightbuild: a triple-core machine with 4GB ram is not sufficient to run
it.
Hi everyone,

Me too comments are not helpful to making a decision in this bug.  Unless you have new information that has not already been raised (apart from it also impacts you), please refrain from commenting.  You can track changes to this bug by adding yourself to the CC list (top right of the page).

Thanks.
Whiteboard: READ COMMENT 25 BEFORE COMMENTING
Well, it seems to me that comment 23 and comment 24 gave new information. Namely, that the performance of TabCandy for them is abysmal. But perhaps a new bug should be filed for that?
(In reply to comment #26)
> Well, it seems to me that comment 23 and comment 24 gave new information.
> Namely, that the performance of TabCandy for them is abysmal. But perhaps a new
> bug should be filed for that?
You mean bug 564978?
First patch here. Guaranteed to be incomplet and inkorrekt.

Still finding my way around the code. Corrections welcome (and necessary).
I *would* have made the option configurable in the Options dialogue, if I knew the code well enough. But since I don't (yet), I just copied how they just wrapped the Mozilla Sync code with ifdef MOZ_SERVICES_SYNC; and I wrapped everything that looked Tab Candy-ish in a ifdef MOZ_TABVIEW.
Attachment #499891 - Flags: review?(ian)
Comment on attachment 499891 [details] [diff] [review]
Allows conditional in/exclusion of Tab Candy at compile time

>+#ifdef MOZ_TABVIEW
> <deck flex="1" id="tab-view-deck">
> <vbox flex="1">
>+#endif

The <deck> should probably exist either way (and it should have a better id) for extensions to overlay the browser similarly to Panorama.

>     <toolbar id="TabsToolbar"
>              fullscreentoolbar="true"
>              customizable="true"
>              mode="icons" lockmode="true"
>              iconsize="small" defaulticonsize="small" lockiconsize="true"
>              aria-label="&tabsToolbar.label;"
>              context="toolbar-context-menu"
>+             defaultset="
> #ifdef APPMENU_ON_TABBAR
>-             defaultset="appmenu-toolbar-button,tabbrowser-tabs,new-tab-button,alltabs-button,tabview-button,tabs-closebutton"
>-#else
>-             defaultset="tabbrowser-tabs,new-tab-button,alltabs-button,tabview-button,tabs-closebutton"
>+             appmenu-toolbar-button,
> #endif
>+             tabbrowser-tabs,new-tab-button,alltabs-button,
>+#ifdef MOZ_TABVIEW
>+             tabview-button,
>+#endif
>+             tabs-closebutton"
>              collapsed="true">

I'm not sure this works -- I guess it doesn't. But either way, this change isn't needed. If the tabview-button node doesn't exist, it will simply be ignored in the default set.

>       <method name="updateTitlebar">
>         <body>
>           <![CDATA[
>+#ifdef MOZ_TABVIEW
>             if (window.TabView && TabView.isVisible()) {
>               // ToDo: this will be removed when we gain ability to draw to the menu bar.
>               // Bug 586175
>               this.ownerDocument.title = TabView.windowTitle;
>             }
>             else {
>               this.ownerDocument.title = this.getWindowTitleForBrowser(this.mCurrentBrowser);
>             }
>+#else
>+            this.ownerDocument.title = this.getWindowTitleForBrowser(this.mCurrentBrowser);
>+#endif
>           ]]>
>         </body>
>       </method>

This change isn't needed because of the window.TabView check.
(In reply to comment #30)
> >+#ifdef MOZ_TABVIEW
> > <deck flex="1" id="tab-view-deck">
> > <vbox flex="1">
> >+#endif
> 
> The <deck> should probably exist either way (and it should have a better id)
> for extensions to overlay the browser similarly to Panorama.

Aren't we frozen yet? Wouldn't that break extension compatibility for existing extensions which already overlay the deck?
impact on existing extensions would be small either way, since the deck is new in 4.0.
Let's hope that in a years time, when usage metrics inevitably show that this feature is rarely used, it will be completely removed from the default chrome like RSS has been.
Comment on attachment 499891 [details] [diff] [review]
Allows conditional in/exclusion of Tab Candy at compile time

Seems fine enough, though I'm not qualified to do the final review (considering how much of the browser it touches). 

I'd like a driver to weigh in on whether this is something we want, and if it's the approach we want. By making it a compile-time flag, it could be helpful for someone making a special cut-down build of Firefox, but I'm not sure what the purpose of this cut-down build would be.... presumably not mobile (the typical low end device), as that's already covered by Fennec. At any rate, it wouldn't help all those people who want a pref, except for the few who don't mind building their own Firefox.

I don't know what the general practice is here at Mozilla, but it seems like adding this flag (or even a pref) adds an on-going tax in the form of additional dev and test complexity (making sure future changes work both ways the flag could be set). We should only do this if we have a clear idea of why we want it. 

One of our goals with Panorama is for it to have no impact on people who don't use it. I realize we've had problems with that in the past, but we've made great strides and I believe we're on track to achieve this for release.
Attachment #499891 - Flags: review?(ian)
Can you guys explain why this isn't a pref? Being able to disable TabCandy at compile time doesn't seem very useful. I personally wish there was a pref that by default was true, but when set to false, TabCandy would not load at all. (It would be as if it were disabled at compile time.)
Ian:
Some users of Firefox (such as I) are, to varying degrees and for varying reasons, opposed to "feature creep", or even just significantly visible change in general.
Personally I do not understand why Tab Candy (or whatever its name has changed to now), as a feature which does not significantly enhance the browsing experience for me, is elevated beyond the status of all the other addons (such as Tab Mix Plus) and nailed straight into the browser with no way of removal. In my opinion this goes directly against Firefox's key advantage over competing browsers -- customizability. In addition the computer that I am working on needs to be streamlined, if only psychologically. I view the browser as a desk of sorts: merely to hold the contents of the pages that I view; any bells and whistles take up space and create a psychological clutter of sorts. Of course, this is not to say that many people won't find a use for this feature; for instance I know many people who would probably like to visualise their tabs in 'groups'. I am just deeply annoyed that not only is this not an addon, the user gets no choice over whether they get it or not.
Another thing is that I don't think the *concept* is polished and streamlined enough for (a power-user's) daily usage. Although visually laying out the tab 'groups' is nice, it heavily requires mouse usage. I do not see any use in 'naming' tab groups beyond marking it out visually, nor moving tab groups around; nor do I see a key shortcut for switching between tab groups, etc etc. The whole thing seems geared towards casual browsers of the Internet, of which I am evidently not a part.
The performance is yet another issue, which detracts from the usefulness of this feature, but personally it is relatively minor an issue (although the lag during the zoom animation is hilarious). Others' mileages may vary.
Besides, surely by just integrating it into the main codebase causes a far greater on-going tax in the form of additional dev and text complexity than adding an option to disable it. If you were prepared to add a feature in, why aren't you prepared to go all the way and avoid alienating the users who never wanted it in the first place?
Just my two cents.

Philipp:
I totally agree. As I stated originally, I am not yet acquainted with the Firefox codebase to be able to confidently add in all the stuff to support it being a pref. Will work on it later, if I find the time.

---
(Also, how do you "reply" properly on Bugzilla?)
Could such a flag be used by the end user to make a choice during the install process?

@Ian: who's the "we" that had problems in the past?  How did the decision get made to incorporate this feature?  I've been lurking and scouring here and google for insight into how this process works/worked/failed that is on track to jam in a "feature" which seems so specialized without much interactions with the community who will use it.  Did somebody do research and find this was something people were looking for?  I haven't seen that discussion anywhere?  All I've seen is discussion between the people who made it/incorporated it and a scant few users like my self who are incredibly annoyed by it.

From the perspective of someone who doesn't code, this is a feature that is just being rammed through, with no way to avoid it.  The shortcut key took over a well used spot, right between reload and close window.  Using it at all has been against my will every single time.  When I do accidentally open it, it usually screws something up or breaks in some unpleasant way.  Even when it doesn't break, it's a major annoyance.  On both my powerful desktop and my not so anemic laptop, it still wastes time that I would rather not waste.

This really is a huge UX issue.  This is bad press just waiting to happen, and it sure to drive users off.

I'm sorry if this comes off as negative/aggressive, but fact is I've become quite fond of FF and 4 seems to bring in lots of wonderful stuff in terms of performance and streamlining.  The only metaphor I can come up with is that Firefox is becoming more and more like a sports car.  It's edging closer and closer to being a Tesla (Electrolysis ya?), but Panorama/Tab Candy is like somebody's installed a blimp in the trunk that will deploy if you hit that pedal where the clutch used to be.  Sure, you shouldn't accidentally be hitting the clutch in a car that needs none, but it's still there.  Yeah, you've made something that gets back up to speed right quick, but still, it completely takes over and stops you any time it happens.  To call it unpleasant is an understatement.

It's kludge, with no way around it.  The least someone could do is give an option.  Else it really just doesn't belong at all.

Chrome is gaining popularity.  Why?  It's lean, like FF used to be.

Aza can coddle his baby all he wants.  I'm not convinced the world wants it as bad as he does.
So it sounds like the use case is "people who don't want Panorama to be in Firefox". If the audience for this feature is the intersection of those people and people who are willing to compile their own version, that's too small of a group to make it worth it; therefore a compile flag won't work. An install-time option is not going to work either; Firefox currently has no install-time options, and this doesn't warrant being the first.

If we are successfull in our goal of making Panorama not affect those who don't use it, that's functionally the same as having a pref that's turned off; either way the code would still exist, it just won't be running. For those who can't stand the sight of the menu item and button, and want the key combo changed back, an add-on could easily be made.

As for discussions on whether Panorama should have ever made it into Firefox in the first place, this bug is not the correct forum. Please use dev-apps-firefox, as mentioned in comment 18, if you feel you have something new to add (after reviewing the discussion that has already occurred there).
FWIW, I also managed to hit Ctrl+E accidentally a few times. It was a rather annoying experience. A pref to disable that command seems like it would be nice to have and cheap to maintain.
I haven't accidentally hit the key combo, but I have accidentally clicked the button a few times and its always been a pretty bad experience. I also think a pref to remove the button would be a good thing, even if its in about:config.
(In reply to comment #40)
> I haven't accidentally hit the key combo, but I have accidentally clicked the
> button a few times and its always been a pretty bad experience. I also think a
> pref to remove the button would be a good thing, even if its in about:config.

Come on, you can right click the toolbar and choose Customize, then remove that button manually. This isn't any harder than about:config stuff, is it?
Okay then why not remove both the button and the key combination. Hell, why not just remove the useless feature?
(In reply to comment #38)
> the first place, this bug is not the correct forum. Please use
> dev-apps-firefox, as mentioned in comment 18, if you feel you have something
> new to add (after reviewing the discussion that has already occurred there).

You're actually trying to say that simple folk like myself should go to the abovementioned mailing list archives, carefully go through 10 pages of search hits for "tabcandy" and then engage into an endless discussion on how depressingly useless the feature is with the people who actually erm, developed it and who would go an extra mile to flame one down to bits just because they desperately want their code included in the release? Bollocks.

People don't listen to the voice of reason, which is users. The users who actually took time to create an account here, go through the bug list and provide their input perhaps care a little more than the majority of the users, who'll swear to themselves and go for one of the many browsers available these days.
Come on folks...most of you know better.  Discussion belongs in the newsgroups per comment 18 and comment 19.
@Ian: thank you for the semi-useful information.  Tells me how to go about it, and that going about it should be a hell of a lot easier than it is.  Alexander is right--this Panorama debacle in the making speaks of poor communication between the devs and the end-users.

An add-on to remove an add-on?  There seems to be a deep flaw in that logic.  This IS a niche add-on type of feature that is impacting people trying the beta, who are certainly going to exhibit more patience than the majority of end users who, agreeing again with Alexander, will encounter this "feature" get **** off and throw FF out the proverbial window.

@Shawn: that's not helpful.  Every other channel has deferred, and if this one closes, something's gonna pop.
Here's potentially relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=589412

Howsabout reopening it?
bodhisattvah: Shawn has asked nicely; please don't make us switch from carrots to sticks. You may have to accept that it could just be that the discussion has been had and your side didn't win.

If you want to continue to make your points, mozilla.dev.apps.firefox is the place to do it:
https://www.mozilla.org/about/forums/#dev-apps-firefox

Gerv
@"Gerv": Don't be rude.  It's posted enough times.

This bug has made it this far, so it's patently obvious that the discourse other places has failed.  This is turning into a devs vs. users thing, and it ought not.

Users are coming here because devs are failing to address the issue.  Again, this needs to be fixed now, because a couple friendly people running beta have been nice enough to point it out give the devs the opportunity.  But a large mass of users upgrading and encountering this are going to flip out and cause lots of problems.  The discussion here has me concerned that this bug report will end in "WONTFIX" or that this will make it to the full release.

I'd like to see FF go forward and be popular.  That isn't going to happen with this feature.

This isn't a popular plugin that got incorporated.  It's being rammed through.

Either give the users a way to remove it, or just get rid of it.  The average user isn't going to compile their own copy.  A switch at compile doesn't address the issue.
bodhisattvah: you have been asked to stop discussing this here, several times, by senior Mozillians. I am disabling your account until you agree that you will do that.

Gerv
Gerv, I think disabling bodhisattvah's account was wrong. If someone doesn't want to see the discussion on this bug, they don't have to be on the CC list. He wasn't being abusive to anyone, which is usually the criteria for disabling an account.

Also, I don't think a decision has been made here, so saying one side has "won" or "lost" would be premature.
Group: mozilla-confidential
sorry, I did not mean to mark this as confidential.
Group: mozilla-confidential
Brad: I got private mail asking me to deal with the situation. I asked him nicely to respect what he was asked to do, but that didn't happen. Given the choice between an irritated senior contributor, and an irritated person who wants to voice his opinion, I go for the latter every time.

He is welcome to have his account back, as soon as he agrees to take this discussion to the appropriate forum.

Gerv
No longer blocks: 585689
Depends on: 627248
Considering a lot of common users are waiting for rc to have their first taste of fx4, I think this bug should at least block rc. Can you imagine how furious they would be when finding out fx4 preinstalled a useless "addon" that not only can't they uninstall but can't even disable? especially when they are told fx4 can (still?) be "made just the way you like it".
I support this option, because this feature is too resource intensive, too slow and too buggy.
This should not be about what I or someone uptown wants or about wining and losing because firefox belongs to all and we must have our say about what is good for it and what is not. I consider it an add on without disable feature and which sometimes activates due to some keys and puts my session into danger of being lost.
> If we are successfull in our goal of making Panorama not affect those who
> don't use it, that's functionally the same as having a pref that's turned off

Is this still (or was it ever) a goal?

> Come on, you can right click the toolbar and choose Customize, then remove
> that button manually. This isn't any harder than about:config stuff, is it?

I updated my nightly today and there's now a 'Tab Groups' option at the top of my tabs drop down list, in prime position for accidental clicking.  Is there any way to remove that?  Or does this mean there is finally a plan afoot to allow disabling of the feature?
> > If we are successfull in our goal of making Panorama not affect those who
> > don't use it, that's functionally the same as having a pref that's turned off
> 
> > Come on, you can right click the toolbar and choose Customize, then remove
> > that button manually. This isn't any harder than about:config stuff, is it?
> 
Imagine there is a toad in your house, it's harmless, it doesn't bark, doesn't bite,just crawling in the corner. but it's there and you can see it from time to time.
Now we are asking is actually a placebo, just cover it up, hoping we can forget its existence over time. is that too much to ask? now we don't dare to ask to get it out of the house since it's somebody's pet (maybe) .
Whiteboard: READ COMMENT 25 BEFORE COMMENTING → READ COMMENT 25 BEFORE COMMENTING, [gems 58]
Finally, there is hope.
http://www.palemoon.org/pm4-dev.shtml
Removal planned:
This feature is too resource intensive, too slow, too buggy.
I totally agree: the feature is too resource intensive, too slow, too buggy.
That's just why I don't use it!!!
For those thinking like me, it's not necessary to have a feature to unable/disable it:
Just drag the TabCandy (now Panorama)icon into the Customize window (right click on the space between the addressbar and the search bar and select Customize in the context menu)!!!
I did that months ago, but I can't find any way of removing the icon that recently appeared in my tab list drop down.
(In reply to comment #48)
> bodhisattvah: Shawn has asked nicely; please don't make us switch from carrots
> to sticks. You may have to accept that it could just be that the discussion has
> been had and your side didn't win.
> 
> If you want to continue to make your points, mozilla.dev.apps.firefox is the
> place to do it:
> https://www.mozilla.org/about/forums/#dev-apps-firefox
> 
> Gerv

Please, bugzilla is not for user support. Support is available at the link in Comment 48 (included here) and/or the mozillazine forums at http://forums.mozillazine.org/index.php

Thank you for your consideration.
(In reply to comment #61)
> I did that months ago, but I can't find any way of removing the icon that
> recently appeared in my tab list drop down.

Why would you need to remove it?
Lets close this bug , there are no complaints on this by new users on FF4/5/6. Devs?
Everyone has been asked not to add comments unless they have new information, how are you determining there are no complaints?

> Why would you need to remove it?

Why would I want to leave an option that I don't want to click on in a prime place for accidental clicking?
(In reply to Rob Crowther from comment #65)
> Why would I want to leave an option that I don't want to click on in a prime
> place for accidental clicking?

It does not have a prime place. It's almost completely hidden from users that don't know about it. Additionally it does not take up any resources if you don't activate it.
Also (correct me if I am wrong on this), the toolbar button is not visible by default.

FYI: I have the addon keyconfig installed. I can use it to disable the keyboard combination, which, I believe, is Ctrl+Shift+E.
(In reply to Ray Murphy (WildcatRay) from comment #67)
> Also (correct me if I am wrong on this), the toolbar button is not visible
> by default.

Indeed, it gets added when you first run Panorama. You can remove it afterwards again (and we won't add it a second time automatically).

> FYI: I have the addon keyconfig installed. I can use it to disable the
> keyboard combination, which, I believe, is Ctrl+Shift+E.

That's the current shortcut, right. Not very easy to hit accidentally IMHO.
(In reply to Tim Taubert [:ttaubert] from comment #68)
> (In reply to Ray Murphy (WildcatRay) from comment #67)
> > Also (correct me if I am wrong on this), the toolbar button is not visible
> > by default.
> 
> Indeed, it gets added when you first run Panorama. You can remove it
> afterwards again (and we won't add it a second time automatically).
> 
> > FYI: I have the addon keyconfig installed. I can use it to disable the
> > keyboard combination, which, I believe, is Ctrl+Shift+E.
> 
> That's the current shortcut, right. Not very easy to hit accidentally IMHO.

Thanks, Tim.

Ironically, I did manage to accidentally hit that key combination--it was a long time, ago--and had no idea what happened or how to "undo" it.

I would be OK with closing this unless there is a compelling reason that has not yet been put forth.
> It does not have a prime place. It's almost completely hidden from users that 
> don't know about it.

If I click on the drop down for 'List all tabs', then 'Tab groups' is the first option on the list.  It's not at all hidden, it's right there at the top of the list.

> Also (correct me if I am wrong on this), the toolbar button is not visible by 
> default.

You're correct, but that wasn't what I was talking about.
FYI-The Tab Groups menu item shows only if the pref browser.allTabs.previews is set to False, the default setting for this pref at this time. If the pref is set to True, a preview of all open tabs is displayed without anything that would appear to invoke Tab Groups

Being under "List all tabs", Tab Groups does not appear to be "out in the open" and one would think it should be fairly easy to not click on.
So there's no way to get a simple (and quick) list of tabs without having the the 'Tab Groups' option?

> one would think it should be fairly easy to not click on

Why can't it be completely impossible not to click on?  Why should anyone have to devote any effort at all, even a 'fairly easy' amount of effort, to avoiding a feature they don't want to use?

Accidental mouse clicks can happen all the time, if the mouse bumps into the keyboard, if the finger slips when activating the drop down, on slightly unreliable laptop touchpads.
I guess current implementation since few versions is fine , we can close this.
Little to no interaction now , doesn't bother those who don't need it.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
The current implementation still doesn't allow you to remove tab groups from the tab drop down menu as far as I can see.  That doesn't appear to have changed in recent versions, why would the status of the bug need changing?
Nope, still pops up when one hits "ctrl-shift-e" on windows, which is easy to do accidentally when trying to hit "ctrl-shift-r" which is a hard refresh.  There's currently no way to disable it and it has been remapped several times.  Not know where it's going to pop up next, the a preferable solution for many users would be an option to remove.

Read through this long comment thread and you should see that marking invalid is an unacceptable solution.
Right. Nothing has been changed feature wise in this bug in the latest versions. There is no UI and even no hidden preference to disable Tab Groups. Reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: Add Option to disable TabCandy (TabSets) → Add Option to disable Tab Groups (Panorama)
My point was it doesn't bother anyone anymore . And if you talk about "feature changes" since Firefox 4 , yes there have been many , now you don't see "Move to Group" in context menu of tabs unless you are using or have more than 1 group in TabCandy. Furthermore , the icon also doesn't appear unless you use it. That hotkey , i don't know how can a normal user could possibly by mistake press ctrl + shift + e , even if he does , he would just explore it and return , and it won't bother ever. 

Giving option to disable (now) will just remove the hotkey function and a context menu option from drop down button (which itself has very low click rate as per 2012 heatmaps). Anyways , devs can work over it as they were since 2010 to disable it :)
> My point was it doesn't bother anyone anymore

How are you measuring that?  It still bothers me.  Do you really want people to post 'me too' on this defect just prove it bothers them?

> remove the hotkey function and a context menu option from drop down button

So basically both features that anyone mentioned the last time you suggested closing it haven't changed?

> (which itself has very low click rate as per 2012 heatmaps)

If people aren't clicking on it anyway surely that's just another argument to hide it?
I understand your concerns, Rob, but as bogas04 points out, panorama in its current state is very low-overhead. I don't think we want to do the work of adding an option just to protect against accidental key presses (Cmd/Ctrl+Shift+E and the tab menu option aren't very easy to hit).
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WONTFIX
For those keeping score, this is happening: Bug 836758
(In reply to bugzilla from comment #81)
> For those keeping score, this is happening: Bug 836758

No, it is being talked about.
That is what I'm saying.  Please see comment #25.
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: