Option to disable TabCandy
Matthew Turnbull
It was suggested that I bring this discussion to the mailing lists, so I am.
Bug 587273 - Add Option to disable TabCandy (TabSets)
https://bugzilla.mozilla.org/show_bug.cgi?id=587273
Right off the bat, I don't want to turn this into a discussion about the
merits of TabCandy or it's usability. I'm primarily concerned with the
functional overhead, its impact on users who don't actually use it, and
the way its landing was handled.
I guess my first observation is that often, when large features are
landed (IPC, HTML5 parser, hardware acceleration, etc), it is pref'd off
by default while it's still worked on. To be honest, I would have liked
to have seen this happen with TC. It's been a week since landing and
there are still usability, behavioral, and performance regressions that
appear to be linked to TC.
- Higher memory usage (possibly leak). To be honest I'm having trouble
replicating this on newer builds, but it was a pretty bad problem a few
days ago. I was seeing 2x memory consumption that slowly grew over time.
I'm not seeing that right now, but I'm keeping an eye on it.
- Tabs being un/re-grouped seemingly randomly. I'm not sure if this is a
problem anymore, but I didn't have a reliable way to reproduce so I'll
just have to see what happens during regular browsing.
- Occasional UI hangs, and sometimes noticeable delays when clicking
links (http://failblog.org an co. often exhibit this), using
back/forward navigation, scrolling, and switching tabs. After a while,
general UI sluggishness.
- Unable to have as many tabs open before Firefox becomes bogged down.
Granted, I don't know whether or not all of that is directly related to
TC. But being able to disable it would be helpful in pinning it down.
Also, for the individuals not interested in using or testing TC, like my
self, it'd be nice to have the ability to disable it. That way we can
focus on other testing and bug tracking without the annoyances of TC
while it slowly gets polished.
My second concern is what's the expected overhead of TC? While I'm sure
there will be groups of enthusiasts who'll love TC, I'm not sure how
well it will be adopted outside those groups. I'm willing to bet that
the majority of users who know about TC will either find no utility in
using it or do not want to change their browsing habits. I personally
fall into the former group, as I find using multiple windows much easier
to use and manage.
So there may potentially be a large percentage of users who aren't
'actively' using TC. What kind of impact will this have on them? For
example, are the 'group view' layout and thumbnails going to be actively
kept up-to-date while the user browses? What kind of resource
(memory/CPU) consumption is expected? Will TC actively make its presence
known?
My thought is that, if an individual doesn't want to use tab groups, or
has no use of them, then TC shouldn't actively be doing anything or
consuming any resources. So my hope is that either TC will be designed
to work that way by release, or have an option to disable it.
In the bug, another person brought up that, if TC does have a noticeable
overhead, it may be desirable to disable it, especially on lower-end
systems. Remember, as it's name indicates, TC is feature candy. It
should not be preferred over usability and performance.
In the bug, someone also brought up that having an option to disable TC
would somehow negatively impact discoverability. I'm not really sure
about the reasoning behind this. If the feature is enabled by default, I
do not see how such a preference 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.
Another point that was brought up was "[Mozilla] generally [doesn't]
have 'hide all existence of this feature' prefs". While this is mostly
true, it's also not really what we're asking. For example, it's possibly
to disable all types of history. Doing this doesn't hide all traces of
it (i.e. menu and toolbar items), just disables it. I don't see why the
same can't be true for TC. The menu and toolbar items don't need to be
hidden, just disabled. It can then be up to the user to hide them if
it's desired.
Also, many of the features that have recently been integrated into the
browser (i.e. Personas, Sync, etc...) don't do anything unless they're
actually used. However, TC does seem to have a more active presence, and
it's tendrils go deeper into the browser than much of the other feature
candy. So it does seem to be more of a special case.
So there you go. My thoughts on TC. Hopefully this at least evokes some
thought on the future of TC and how it impacts users who don't actually
use it. I know that some of these issues may be mitigates by things like
the view/model separation and reworking the 'heartbeat', but I still
have concerns about it. And I don't think it's an unreasonable request.
Matthew Turnbull
--
Bluefang-Logic Networks:
Scaled for your pleasure.
Mike Beltzner
First and foremost, please file bugs. Tabcandy was only allowed to land when it caused zero performance regressions and passed all tests. Blocker bugs are filed for the one test that it interacted poorly with.
Second, the team is building a command line switch for enabling and disabling tabcandy (compile time, I think) but I do not believe it is a good user experience to make it a user option. If we can't get it to work, we shouldn't ship it. Period. So far, though, I believe we are on track to have it working, and well.
We build our product through iterations and broad feedback. We cannot tell nor test all use cases, and all UI interactions. We don't have the tools or the person power to do this. So we iterate until it reaches a quality bar for landing (in this case on a project branch and build servers, like tracemonkey) and then we rely on beta level feedback. Beta 4 will be that milestone. The team is blocking and tackling bugs as they come up.
The memory leak (we weren't closing tabs, just hiding them) was resolved in the latest nightly, as I believe are a couple of the other bugs you referenced.
I agree that Tabcandy should not consume resources until it is invoked. The zero impact on memory, CPU, startup and pageload tests indicate that to be true, as well as the lack of leaks. If we find others, we'll block on fixing them.
(Please note that some recent changes in trunk nightlies - not related to Tabcandy or Sync - have caused such regressions and not yet had those regressions resolved. Perhaps that is what you are seeing?)
In short, I appreciate the feedback, but do not see the evidence you do that the problems you're seeing are tabcandy related. Hopefully the command line switch will allow us to test these hypotheses further.
As I said, though - please file bugs!
cheers,
mike
Matthew Turnbull <spa...@bluefang-logic.com> wrote:
Hello everyone,
Matthew Turnbull
--
Bluefang-Logic Networks:
Scaled for your pleasure.
_______________________________________________
dev-apps-firefox mailing list
dev-apps...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-firefox
Martijn
> Hi Matthew,
>
> First and foremost, please file bugs. Tabcandy was only allowed to land when it caused zero performance regressions and passed all tests. Blocker bugs are filed for the one test that it interacted poorly with.
>
> Second, the team is building a command line switch for enabling and disabling tabcandy (compile time, I think) but I do not believe it is a good user experience to make it a user option. If we can't get it to work, we shouldn't ship it. Period. So far, though, I believe we are on track to have it working, and well.
Why not use a pref in about:config?
Regards,
Martijn
--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Mike Connor
On 2010-08-19, at 5:56 AM, Martijn wrote:
> On Thu, Aug 19, 2010 at 5:47 AM, Mike Beltzner <belt...@mozilla.com> wrote:
>> Hi Matthew,
>>
>> First and foremost, please file bugs. Tabcandy was only allowed to land when it caused zero performance regressions and passed all tests. Blocker bugs are filed for the one test that it interacted poorly with.
>>
>> Second, the team is building a command line switch for enabling and disabling tabcandy (compile time, I think) but I do not believe it is a good user experience to make it a user option. If we can't get it to work, we shouldn't ship it. Period. So far, though, I believe we are on track to have it working, and well.
>
> Why not use a pref in about:config?
Doing something with a pref is more complicated than a build switch, and is more work to maintain.
Our test matrix is already complex, adding even more prefs doesn't help that. Personally, I think we should kill hidden prefs before we add more.
-- Mike
John Bird
the Group your Tabs screen on startup.
I did some tests, if Minefield is started with no Internet connection it
does retrieve all this information, at about the same speed as if online,
maybe slightly faster as no loading of pages was done. Very good to know
you thought of that.
Whether online or not - the Group by Tabs window is built up at about 1 tab
icon per second retrieved, or a little slower - and there are pauses and
gaps. So if I have 100 tabs - well thats 100+ seconds to get going.
Until a tab icon is retrieved from where it is stored for a group, there is
just a blank group that cannot be clicked on. If 2 of the 20 in a group are
there clicking will give only those 2 tabs.
So it has the info it just is too slow to load it - there's the main issue
guys!
Or figure a way to store the whole structure on exit in a way that can be
loaded next to instantly.
Its achingly beautiful and frustrating to use. So far its a Windows Vista
type invention. Turn it into a Windows 7/Mac experience....
John Bird
chris hofmann
problem turns up in tab candy or other features an intermediate fix is
to disable the feature, until a proper fix can be delivered.
-chofmann
> -- Mike