<div dir="ltr"><div>I like having this option back, as I know this was a feature that a lot of people liked in the past.  (even though I'm personally ok with the 100px width)</div><div><br></div><div>I've been trying to use the new default (50px) for a couple of hours, and it felt surprisingly unusable, in a way that I couldn't quite figure out why. After a while, I think I've reached the explanation: <br></div><div><br></div><div>The purpose of overflowing tabs is to prevent them to go shrink to unusable sizes.. Even at 50px, I have enough tabs open to make it overflow. So it overflows, but the tabs won't grow back to something more usable, so what happens is that I have a tab strip full of unreadable tabs, and it still scrolls  (i.e., there was no benefit in the smaller min-width, only downsides)<br></div><div><br></div><div>It would be nice if the tabs would grow again a little bit when overflow happens, but that is probably too daunting visually. So I know this is a no-go.<br></div><div><br></div><div>Playing with the value, I actually really liked 80px, and I can see that winning in favor of 100px.  We could perhaps go as low as 75, but IMHO that would be the limit.</div><div><br></div><div>my 2 cents</div><div>Felipe<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 3, 2017 at 5:36 PM, Jeff Griffiths <span dir="ltr"><<a href="mailto:jgriffiths@mozilla.com" target="_blank">jgriffiths@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
tl;dr we changed the default pixel value at which we overflow tabs,<br>
and I want your feedback.<br>
<br>
We just added a change to m-c[1] that does to things:<br>
<br>
1. it reintroduces an old preference 'browser.tabs.tabMinWidth' that<br>
contains a pixel value that controls the minimum width of a tab.<br>
<br>
2. it sets the default value of the tab to 50, previously this value<br>
was hard-coded at 100.<br>
<br>
Work is being tracked in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1404465" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1404465</a><br>
<br>
We did this based on some early feedback from a few different sources<br>
that people coming from chrome ( or in some cases, existing users )<br>
thought that the Firefox behaviour of scrolling the tabstrip was<br>
off-putting. We looked into this and I generally agree with the<br>
comments: chrome's "infinite tabs visible" approach results in a much<br>
higher usable/visible tab count in a given window than ours does. This<br>
change puts us roughly at par.<br>
<br>
To put this in numbers:<br>
 * in chrome I can open ~ 24 tabs before the tabstrip's usability is<br>
degraded a lot<br>
 * in current firefox, I can open ~ 12 tabs before tabstrip scrolling kicks in<br>
 * with this change applied I can open 25 tabs with the pref value set to 50px<br>
<br>
( Caveats: this was on the built-in display on my Macbook Pro with the<br>
default theme, your mileage may vary, etc )<br>
<br>
I want feedback on this change from these lists, and will also be<br>
looking for feedback from the original sources of this complaint. In<br>
particular:<br>
<br>
1. do you prefer the existing behaviour or the new behaviour?<br>
2. if you prefer a value for this pref different than 50 or 100, what<br>
is it? Why?<br>
<br>
One aspect that I would like to stress about this change: most<br>
existing Firefox users will never see it, because they are unlikely to<br>
open m,ore than 10 tabs at any one time. So what we are really talking<br>
about is a change that will trade being able to see more tabs vs being<br>
able to read more text in each tab title.<br>
<br>
Moving forward there are a few different options:<br>
<br>
1. uplifting this change into 57 ( possibly with a different default<br>
value ) If we think the patch has a generally positive effect and no<br>
downsides, we may decide to uplift into 57 Beta and let it ride the<br>
trains.<br>
<br>
2. keeping the change in 58, possibly with a different value.<br>
<br>
3. keeping the change in 58, preserving the current setting of 100px<br>
and providing an alternate pref ( probably a toggle or predefined<br>
values ) for "skinnier" tabs.<br>
<br>
Longer term I intend to propose a more in-depth study of tab behaviour<br>
among different user segments and assess different strategies for<br>
heavier tab users including things like horizontal tab scaling,<br>
vertical tabs, etc. I can't see that happening before Q1 next year.<br>
<br>
cheers, Jeff<br>
<br>
[1] <a href="https://hg.mozilla.org/integration/autoland/rev/a75e0386aad8" rel="noreferrer" target="_blank">https://hg.mozilla.org/<wbr>integration/autoland/rev/<wbr>a75e0386aad8</a><br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
</blockquote></div><br></div>