<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hey!<br>
</p>
<p>I'm with Brendan Barnwell here. As an other user who opens lots
and lots of tabs. I use tabs as To-Do and with lots of parallel
work based on context and day and need to have lots of work
pending while jumping to something else.</p>
<p>I'm someone who works with 300-900 tabs, every day using nearly
100 of them; sometimes keeping them opened to continue later.</p>
<p>Although I'm not keen of Tab Mix Plus, although I'm a heavy user
of the currently abandoned Tab Groups (by quicksaver) currently
with 27 groups from which I use 15 every day and all 27 every
month.</p>
<p>With such high count of tabs, when I try to use chrome, I suffer
from the same problem as Brendan Barnwell where I lose direct
access to the tabs after the 30th or so. The only way to access
them being to CTRL + TAB to reach the right one while, now, I can
just double click the arrow to scroll the tabs bar in "pages" and
click the one I want.</p>
<p>Anyhow, having '<tt>browser.tabs.tabMinWidth</tt>' available for
use can mitigate the situation by allowing the scroll I rather use
than not know what each tab is about.</p>
<blockquote>
<pre wrap="">1. do you prefer the existing behaviour or the new behaviour?</pre>
</blockquote>
<p>
I like the current one quite much but I understand well how
non-power users can highly prefer that new proposed behavior. From
me, I don't mind. I can just tweak the configuration to my own
taste.</p>
<blockquote>
<pre wrap="">2. if you prefer a value for this pref different than 50 or 100, what
is it? Why?</pre>
</blockquote>
<p>The current one in FF 35 (100) is, at least, nearly perfect for
me. It shows the icon and some title content (although some
websites fluke it) to know what the tab is about.</p>
<p>Cheers,<br>
Brunoais</p>
<br>
<br>
<div class="moz-cite-prefix">On 03/10/2017 21:36, Jeff Griffiths
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKZskdbu5ntMa+nhsDwJSjEApPSEzn5NanbaXc-k6uQCguWusQ@mail.gmail.com">
<pre wrap="">Hi!
tl;dr we changed the default pixel value at which we overflow tabs,
and I want your feedback.
We just added a change to m-c[1] that does to things:
1. it reintroduces an old preference 'browser.tabs.tabMinWidth' that
contains a pixel value that controls the minimum width of a tab.
2. it sets the default value of the tab to 50, previously this value
was hard-coded at 100.
Work is being tracked in <a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1404465">https://bugzilla.mozilla.org/show_bug.cgi?id=1404465</a>
We did this based on some early feedback from a few different sources
that people coming from chrome ( or in some cases, existing users )
thought that the Firefox behaviour of scrolling the tabstrip was
off-putting. We looked into this and I generally agree with the
comments: chrome's "infinite tabs visible" approach results in a much
higher usable/visible tab count in a given window than ours does. This
change puts us roughly at par.
To put this in numbers:
* in chrome I can open ~ 24 tabs before the tabstrip's usability is
degraded a lot
* in current firefox, I can open ~ 12 tabs before tabstrip scrolling kicks in
* with this change applied I can open 25 tabs with the pref value set to 50px
( Caveats: this was on the built-in display on my Macbook Pro with the
default theme, your mileage may vary, etc )
I want feedback on this change from these lists, and will also be
looking for feedback from the original sources of this complaint. In
particular:
1. do you prefer the existing behaviour or the new behaviour?
2. if you prefer a value for this pref different than 50 or 100, what
is it? Why?
One aspect that I would like to stress about this change: most
existing Firefox users will never see it, because they are unlikely to
open m,ore than 10 tabs at any one time. So what we are really talking
about is a change that will trade being able to see more tabs vs being
able to read more text in each tab title.
Moving forward there are a few different options:
1. uplifting this change into 57 ( possibly with a different default
value ) If we think the patch has a generally positive effect and no
downsides, we may decide to uplift into 57 Beta and let it ride the
trains.
2. keeping the change in 58, possibly with a different value.
3. keeping the change in 58, preserving the current setting of 100px
and providing an alternate pref ( probably a toggle or predefined
values ) for "skinnier" tabs.
Longer term I intend to propose a more in-depth study of tab behaviour
among different user segments and assess different strategies for
heavier tab users including things like horizontal tab scaling,
vertical tabs, etc. I can't see that happening before Q1 next year.
cheers, Jeff
[1] <a class="moz-txt-link-freetext" href="https://hg.mozilla.org/integration/autoland/rev/a75e0386aad8">https://hg.mozilla.org/integration/autoland/rev/a75e0386aad8</a>
_______________________________________________
firefox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>