Re: Changes to tab min-width

[Boris Zbarsky]

On 12/5/19 6:51 AM, smurf4234332342342342342...@gmail.com wrote:

This re-introduced setting doesn't seem to exist


It's there in about:config... are you not seeing it there?

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Wade]

I am aware of browser.tabs.tabMinWidth  but it seems to have a minimum of 40 or 
50. Setting it lower has no affect.

This was the point of my message. I would like to set it to 10 or 15 or even 0 
for infinite shrinking.


Wade

> On November 18, 2017 at 1:22 AM Dirkjan Ochtman  wrote:
> 
> On Sat, Nov 18, 2017 at 7:38 AM,  mailto:w...@vapor4life.com > wrote:
> 
> > > 57 is unusable for me..I keep 35-50 tabs open at any given time 
> and I used Custom Tab Width legacy extension to prevent scrolling. I CANNOT 
> stand scrolling thru tabs. I don't need to read the tab- I KNOW where they 
> are. It should be simple to allow tabminwidth to go lower than currently 
> configured. Then the user could decide how THEY like it. If this doesn't 
> happen soon I will be reverting to an older versio nof FF or switching 
> browsers altogether. btw..there is still some memory leak with FF. After a 
> day I have to restart FF or it would eat all remaining Mem on my 8G system.
> > 
> > > 
> Luckily, Firefox has your back. From the first message in this thread:
> 
> On Tuesday, October 3, 2017 at 3:36:40 PM UTC-5, Jeff Griffiths wrote:
> > 1. it reintroduces an old preference 'browser.tabs.tabMinWidth' that
> > contains a pixel value that controls the minimum width of a tab.
> 
> Which you can easily set to a different value that works better for you.
> 
> Cheers,
> 
> Dirkjan
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[John Scineram]

On Tuesday, October 3, 2017 at 11:18:14 PM UTC+2, Boris Zbarsky wrote:
> On 10/3/17 4:36 PM, Jeff Griffiths wrote:
> > 2. it sets the default value of the tab to 50, previously this value
> > was hard-coded at 100.
> 
> Jeff,
> 
> So just to make sure I understand the change (and this is a theoretical 
> point, because I haven't had a chance to try the change yet)...  Right 
> now, the min tab width is 100.  This contains the following pieces:
> 
> 1)  18px of horizontal padding (on the .tab-content).
> 2)  16px of favicon.
> 3)   6px of favicon right-margin.
> 4)  60px of space for the page title.
> 
> With the new setup, just looking at the patch, the main thing that 
> changes is that the page title space drops from 60px to 10px when enough 
> tabs are open, because none of the other values change, right?
> 
> Right now, at 60px, I can see 7-10 chars in a tab title.  This is 
> sometimes (but not always) enough for me to make sense of what I'm 
> looking at when the favicon is not helpful.  For example, for bugzilla 
> bugs I can see the whole bug number.
> 
> In the new setup is sounds like I will see 1-2 chars.  At that point, 
> it's not immediately clear to me that there's any value to not just 
> setting the min-width to "40px" and allowing all the title text to 
> disappear altogether.  There is definite value in not going below the 
> "keep the favicon entirely visible" value, of course.
> 
> > We looked into this and I generally agree with the
> > comments: chrome's "infinite tabs visible" approach results in a much
> > higher usable/visible
> 
> I think there's a difference here between "usable" and "visible" 
> And yes, I understand that I can just set the pref as needed.
> 
> > 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.
> 
> Just fwiw, at the 100px width, tabstrip scrolling kicks in for me at 9 
> tabs.  It's possible that most of our users have wider windows than 
> mine, of course.
> 
> I will definitely try experimenting a bit with this pref to see how 
> things behave in practice.
> 
> -Boris

85 is minimum for me. That corresponds to 35 for text. Reduce padding by 10 as 
Ehsan showed, and 75 or 80 is usable. Running 100 for now.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Dirkjan Ochtman]

On Sat, Nov 18, 2017 at 7:38 AM,  wrote:

> 57 is unusable for me..I keep 35-50 tabs open at any given time and I used
> Custom Tab Width legacy extension to prevent scrolling. I CANNOT stand
> scrolling thru tabs. I don't need to read the tab- I KNOW where they are.
> It should be simple to allow tabminwidth to go lower than currently
> configured. Then the user could decide how THEY like it. If this doesn't
> happen soon I will be reverting to an older versio nof FF or switching
> browsers altogether. btw..there is still some memory leak with FF. After a
> day I have to restart FF or it would eat all remaining Mem on my 8G system.


Luckily, Firefox has your back. From the first message in this thread:

On Tuesday, October 3, 2017 at 3:36:40 PM UTC-5, Jeff Griffiths wrote:
> 1. it reintroduces an old preference 'browser.tabs.tabMinWidth' that
> contains a pixel value that controls the minimum width of a tab.

Which you can easily set to a different value that works better for you.

Cheers,

Dirkjan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[wade]

On Tuesday, October 3, 2017 at 3:36:40 PM UTC-5, Jeff Griffiths wrote:
> 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1404465
> 
> 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] https://hg.mozilla.org/integration/autoland/rev/a75e0386aad8

57 is unusable for me..I keep 35-50 tabs open at any given time and I used 
Custom Tab Width legacy extension to prevent scrolling. I CANNOT stand 
scrolling thru tabs. I don't need to read the tab- I KNOW where they are. It 
should be simple to allow tabminwidth to go lower than currently configured. 
Then the user could decide how THEY like it. If this doesn't happen soon I will 
be reverting to an older versio nof FF or switching browsers altogether. 
btw..there is still some memory leak with FF. After a day I have to restart FF 
or it would eat all remaining Mem on my 8G system.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Boris Zbarsky]

On 10/10/17 1:11 PM, Jeff Griffiths wrote:

This is highly dependent on screen size.


It's dependent on window size.  And I was just pointing out that the 
post I was replying to assumes that "12 or fewer tabs" means "not 
scrolling", whereas we have no obvious data to that effect.


That is, we have telemetry for number of tabs.  We have telemetry for 
screen sizes, iirc.  I don't know whether we have telemetry for _window_ 
sizes at all.  And we don't have telemetry for "window size divided by 
number of tabs", which is what we would need to know what fraction of 
people have overflowing tabs.


We could approximate this last if we have telemetry for window size (or 
assume that window size closely tracks screen size) and assume that 
number of tabs is uncorrelated with window or screen size.  But it's not 
clear to me how justified such an assumption would be.


I was addressing just this one statistical analysis point, not the 
broader question of what the right behavior is here.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Jeff Griffiths]

On Oct 6, 2017 07:50, "Boris Zbarsky"  wrote:

On 10/6/17 9:52 AM, Nicolas B. Pierron wrote:

> I will add that 91% of the session on release have 12 or fewer tabs, and
> thus would not be concerned at all by these changes.
>

Do we actually know that?

As I said upthread, at the 100px tab width my tabs start to scroll when
adding the 9th tab.



This is highly dependent on screen size. For me it's 12, for you 9, on
large desktop LCD monitors probably 20+.

The more interesting comparison to me is "tab identifiability" ( heh ) vs
chrome, which is a complex issue. Feedback has included questions about
reduced identifiability with two extreme points of view expressed: people
who think favicons are enough, and people who need some tab title context.
I take very seriously the use case for the latter expressed here - lots of
tabs opened to the same site.

In this first phase, the question is, what is the minimum thing we can do
to tackle this issue and the feedback. We've uncovered a number of aspects
of the tab design that impact "tab identifiability" that causes problems
for some users at various settings, but a more complex patch to address
these in some way is out of scope. We simply don't have time.

To bring this discussion to a conclusion, after some discussion in the second
bug  we're landing a
patch that re-introduces the preference, and sets the minimum to 76. There
are some remaining edge cases that aren't a great experience, but we think
the improvement is worthwhile overall and in particular having the pref
available is necessary as this seems to be a very polarizing issue.

Stephen and I will be working wit the UX and frontend teams on strategies
to mitigate the problems we uncovered by looking into this, I hope to see
things improve over the next few cycles.

thanks, Jeff



-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Miha]

When I first saw tabs shrink in Firefox 58a I thought it's a nasty bug and I 
started reporting it to Bugzilla. I found this thread and I'm glad this 
negative behaviour is open to discussion.

As soon as I read it's possible I have used 'browser.tabs.tabMinWidth' to 'fix' 
the change. I have changed the numbers a bit and 95 plays nice with me. This is 
how I see this:

1. I use many tabs (200+). If all tabs have the width of 50, then there's only 
the favicon shown. Which, as already noted by others, will be the same for many 
tabs. Not to mention that some sites don't have a favicon, so they will all 
look the same. Not to mention that this way all tabs look similar or almost the 
same as pinned tabs.

2. Before FF 57 I was using "Faviconize tab" add-on (it doesn't work with FF57 
any more because of WebExtensions). It enables to select the tab and make it 
shrink to favicon size only (and also expand). That addon was super useful and 
I would welcome this kind of default behaviour. That way the user can choose 
how large the tabs should be. Furthermore, if they want some tabs large and 
some small, they can have them.

3. I'm reading here that some people find tab scrolling to the side 
disorienting. I disagree. It's much more useful than a new row (or rows!) of 
tabs because that one takes screen estate.

4. I'm also reading here that other people find weird that the drop-down tab 
arrow is not visible with a smaller number of tabs and shows up only after some 
10+ tabs are open. I'm one of those, too. Always visible would be preferable.

5. I also agree that tab changes should be based on an experiment focused on 
heavy tabs users and not just on a gut feeling.

6. Since we're debating long-term changes to tab behaviour I would use this 
place to suggest nested tabs or a tree of tabs in the tab row. Right now, one 
tab means one web site. I'm proposing that one tab could mean a drop down menu 
of user-grouped tabs (websites). This way there would be more space available 
for tabs and users could have some tab grouping. There are some addons, but 
they all do this in the sidebar which i use for different purpose.

7. Also, speaking long-term, I welcome Containter tabs. I was sceptic at first 
but after I tried them they're very useful and easy to use. Also, visually 
distinguishable from the rest of tabs. I usually used Chrome before for having 
the second set of tabs open with a different account, but since my computer 
crashed a month ago, I haven't found a need even to install it. I just use a 
few Container tabs.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[testo . moz]

If you introduced the setting, I think it would increase it up to 150px to be 
able to see more tab title.  Particularly when I have a lot of tabs from the 
same site open, it could help.

At this moment I have 45 tabs open in Firefox, and 25 in Firefox Developer 
edition.  Tabs start scrolling for me at about 15.  I do like to just use the 
touch pad on my macbook to side swipe to move between the tabs.  If I have to 
use the < > buttons to move between the tabs that becomes painful as I can 
never get it to stop where I want.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[vmarty89]

In my opinion, the important thing is that this is not about disabling 
scrolling behaviour altogether. This will not affect users with <10 tabs, it 
will possibly help Chrome users with 10-20 tabs, and it will destroy both use 
cases for users with >20 tabs because the tabs will be unreadable AND still 
scroll out of view.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[yoasif]

On Tuesday, October 3, 2017 at 4:36:40 PM UTC-4, Jeff Griffiths wrote:
 
> 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?

1. Prefer old behavior, but can understand the desire for the new behavior as 
well. 

2. I'm trying to keep an open mind and I'm mostly okay with 80px as a balance. 
50 or less would likely look better if we didn't try to show text at all and 
instead showed just a favicon or a close button like Chrome does.  

It feels a bit like you are trying to ape the look of Chrome without trying to 
observe what makes it work -- even though in my mind, it still doesn't work all 
that well. 

As a long time Firefox user, if I want to find a tab, I just use the awesomebar 
% token to find the tab I am interested in, if it's not shown on screen. If it 
is shown on screen, I'm more likely to ctrl+tab/ctrl+shift+tab over to it, but 
the text is often helpful here -- multiple tabs with the same favicon doesn't 
tell me how many tabs I need to pass over to get to where I want to be, unless 
I look at the tab contents, which is the poor behavior that Chrome forces. 

One thing I noticed about Chrome (I opened it to play with their tab behavior) 
is that once the tabs get very pointy, *they overflow*, and in a way that 
doesn't even let users drag the the overflowed tabs to a new window, or to 
close it without using keyboard shortcuts. They overflow into a nether where 
they aren't visible *at all*.

At least Firefox prevents that behavior. 

> 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.

That may be the case, but I currently have 49 tabs open in the tab I am 
composing this message in, and I routinely walk by people at work who have 20 
tabs or so open. 

> Moving forward there are a few different options:

I think that this is being done with very short notice (why are we talking 
about doing this in Firefox 57 - if this was important, shouldn't it have been 
discussed or under planning for a few weeks or months at least?) - or is a way 
to make a change on a whim that you believe will make Chrome users comfortable 
without having to deal with a lot of review? I'd prefer to not look at this 
cynically, but I've seen Mozilla's developers move -- it's generally 
deliberately, and always trying to make the right call. This feels a lot more 
like guesswork. 

Either way, I think this should be a *user facing* preference - the customize 
UI makes the most sense to me, but about:preferences would work too. A live 
slider would probably work great, but a dropdown like exists for density in 
customize should also work. 

I strongly don't believe that this should only be accessible via about:config. 

I also don't think that existing Firefox users should be auto-migrated to this 
preference. If anything, it should only be for new installers where there 
Chrome is already installed (new installers where only Safari/Edge are 
installed show no clear "preference" for the Chrome behavior).

Why also not set up some experiments here targeting high tab users?
 
> 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.

This feels more like a design problem that should probably be solved more 
immediately if you want to push 50px tabs out (which who knows, may be ideal 
for switchers). 

Some suggestions:

1. Don't try to show any text, show favicons/speaker icon when tab get too small
2. Play with the look of the tab bar -- the new default theme looks ugly when I 
have many tabs open at 50px. I'm sure not constraining design to the new Photon 
UI and rethinking some of the look would produce a better result (this is why I 
feel that this is being done on a whim, I don't think design would have let 
this out as it is with 50px; it is *ugly*). Amusingly enough Chrome looks more 
like Australis currently.
3. Pinned tabs behavior feels fine to me. 
4. Don't get rid of overflow. Chrome's behavior is broken.

Note: I prefer the existing behavior, but I hope the above demonstrates that 
this requires more design thinking than doing this on a whim. 

> cheers, Jeff
> 
> [1] https://hg.mozilla.org/integration/autoland/rev/a75e0386aad8

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Randell Jesup]

>> I find (perhaps because I'm a mozilla user, and a tab-hoarder) that
>> Chrome's UI is DREADFUL for anyone with lots of tabs - and probably
>> intentionally to push users into closing them, since large numbers of
>> tabs simply doesn't work as well in Chrome as in Firefox.  So mimicing
>> their behavior is NOT a good idea, IMHO.
>
>I'm one of the people (a minority in this thread, it appears) who prefers
>Chrome's behavior and who'd like a skinny-tab option in Firefox, though not
>necessarily the default option. I use all the major browsers, typically
>with a dozen or more tabs open in the browser I'm using for my primary work
>at any given time. I vastly prefer Chrome's tab behavior for several
>reasons and rely on it as my primary browser in part because of it.

Sounds like a good option for an extension.

>I believe the complaint of "XYZ pixels is too narrow because it hides
>necessary information in the tab" misses another point. For me, having tabs
>vanish off one side or the other of the tab strip is a worse omission of
>important information.

I have enough tabs that there's No Way they can even be visible as close
boxes (and it's useless to me when it gets down to favicon).  And I get
that you have a different set of behaviors/preferences.

An un-discoverable feature of the Awesome Bar is
"%url-fragment/title-fragment".  It will show you completions
from the list of open tabs only.  This (and using scroll-wheels to spin
quickly through a overflowing tab bar) make large numbers of tabs
feasible without going the huge number of windows route.

I think we could do skinnier tabs if we retained the ability to see what
they are (not just favicon) easily.  The more I think of it, the more I
like the dock-like expand-what's-near-the-mouse idea - I wonder how easy
it is?

>I have typically navigate my 20 or 30 or 40 tabs mostly by keyboard,
>cycling one way or the other across the tab strip, and for me the spatial
>arrangement is very important (as is tab-switching speed).

I find spatial organization is also quite useful, but I orient myself to
it visually.  I never use the keyboard nav - don't even know what the
bindings are. :-)

>There is an argument to be made for making life easier for people moving to
>Firefox from Chrome, which clearly is an ambition in the current Firefox 57
>Quantum push. I don't have any data about how widespread my preferences are
>or how much of a barrier it is adjusting to Firefox's disappearing tabs,
>but this heavy Chrome user prefers Chrome's approach.
>
>I'm not trying to argue that my preferences are universal. But I expect
>Google made its choices pretty carefully and not as a way to punish people
>for using too many tabs. I use lots more tabs than the average user, but I
>expect the general trend is drifting toward more and more tabs, so graceful
>handling of overflow will become important for a larger fraction of people
>as time goes on.

Having a option for tab-handling might be good; it's a primary way users
interact with the browser -- and *no* single way is the Right Way for
all users.  Extensions can help here, modulo most users don't look for
them.  You could also offer that (extension or option) when they import
profile data from Chrome, or put a link in Prefs to a Chrome-like tab
WebExtension (Prefs *could* have links to relevant Extensions).

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[stephen . shankland]

> I don't know about you, but a common case for me is go-to-news-site,
> open-N-articles-in-tabs, read-articles (maybe ;-) ).  Probably learned
> that in the days of less bandwidth; stuff can pull down in the
> background.  Saves a lot of go-back,
> wait-for-page-to-load/render/scroll/etc.
> 
> For that usage, I need at least a word or so of the title - N tabs
> together with the same favicon.  Current width mostly works for this.
> 
> I find (perhaps because I'm a mozilla user, and a tab-hoarder) that
> Chrome's UI is DREADFUL for anyone with lots of tabs - and probably
> intentionally to push users into closing them, since large numbers of
> tabs simply doesn't work as well in Chrome as in Firefox.  So mimicing
> their behavior is NOT a good idea, IMHO.

I'm one of the people (a minority in this thread, it appears) who prefers 
Chrome's behavior and who'd like a skinny-tab option in Firefox, though not 
necessarily the default option. I use all the major browsers, typically with a 
dozen or more tabs open in the browser I'm using for my primary work at any 
given time. I vastly prefer Chrome's tab behavior for several reasons and rely 
on it as my primary browser in part because of it.

I believe the complaint of "XYZ pixels is too narrow because it hides necessary 
information in the tab" misses another point. For me, having tabs vanish off 
one side or the other of the tab strip is a worse omission of important 
information.

I have typically navigate my 20 or 30 or 40 tabs mostly by keyboard, cycling 
one way or the other across the tab strip, and for me the spatial arrangement 
is very important (as is tab-switching speed). I keep a mental map where 
everything is, and the tab strip mirrors it. I have different patches of a few 
nearby tabs for related tasks, for example. When some or most tabs are hidden, 
I find I get "lost." One visible tab strip helps me remember what I have going 
on when I lose track during multiasking moments. In Firefox, I have to 
compensate by opening new browser windows (harder than in Chrome since I can't 
select a group of them and tear them away to a new window) to manually 
partition my work into different clusters of tabs.

Chrome gracefully degrades the amount of information visible on each tab in a 
way I find useful. I often have lots of tabs with the same favicon visible 
(Google Docs, news articles from one website, etc) and though it would be nice 
to see full tabs I find the favicon is enough for me to keep my bearings. Most 
of the time, though, I have many different websites open and a glance at the 
favicons is all I need to know what's up.

The audio indicator is indeed a very useful part of the tab UI. In Chrome, it's 
the last thing visible as tabs get narrower, obscuring even the favicon. The 
close box disappears as tabs get narrower, but it's still visible on the active 
tab. When tabs are so narrow that only one item is visible, the close box is 
that single thing (overriding the audio indicator). Google clearly thought 
about this behavior carefully, and I vastly prefer it and often use Chrome for 
my primary work browser purely because I dislike Firefox's disappearing tabs so 
much.

There is an argument to be made for making life easier for people moving to 
Firefox from Chrome, which clearly is an ambition in the current Firefox 57 
Quantum push. I don't have any data about how widespread my preferences are or 
how much of a barrier it is adjusting to Firefox's disappearing tabs, but this 
heavy Chrome user prefers Chrome's approach.

I'm not trying to argue that my preferences are universal. But I expect Google 
made its choices pretty carefully and not as a way to punish people for using 
too many tabs. I use lots more tabs than the average user, but I expect the 
general trend is drifting toward more and more tabs, so graceful handling of 
overflow will become important for a larger fraction of people as time goes on.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[jan . skurski]

Hi, just a (power?) user input here, my subjective POV.

In fact I was a little frightened when that min-width changed in Nightly. I 
liked very much the old behaviour, to see only a fraction of opened tabs (I'm 
nearly always in the overflow territory anyway), disliked Chrome for that 
"compression" of tabs. I don't see anything wrong with scrolling - if I want to 
see all tabs, I have a drop-down option for it, keyboard shortcuts and all.

As I am always at the overflow limit, I am:
1) Not seeing much text at the 50px (75px is not much better for me)
2) simply overwhelmed by that "compression" of tabs - it's highly subjective, 
but very noticable for me. (it's like a psychological discomfort, hard to 
describe it properly)

All in all, I feel comfortable with 100px, even 90px feels a little too low for 
me - not much text shown.

Regards,
Jan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[sciguyryan]

I tend to keep a rather huge collection of tabs open at any one time (ranging 
from hundreds to well over a thousand). I found the 50px length to be unusable 
small.

It was possible to determine which sites were open from their favicon but it 
was impossible to tell what page that was without more investigation. For me 
that was a fundamental breakage to the way I use my browser. I changed setting 
upwards to 70px but still found that 100px (the old default I'm told) gave the 
best results for my own use case. Making it larger than that didn't add much.

My suggestion would be something like this, though I have no idea how it would 
fit into the current UX design or goals:

* Leave the preference to change the tab width within about:config
* Revert the default value of the preference to 100
* Provide a slider option to set this within about:preferences that would let 
people easily fiddle with it without having to poke around in about:config

Since not everyone feels comfortable with fiddling around with the settings in 
about:config it seems sensible to have some way of handling this directly 
within the normal preferences. A slider seems the most strait forward way of 
achieving this.

I would welcome some feedback and thoughts on that suggestion.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Daniel Veditz]

On Fri, Oct 6, 2017 at 12:15 PM, Randell Jesup 
wrote:

> There's "publish an extension that
> ​ ​
> lets you fiddle the width" (doable today).


​WebExtensions can't manipulate prefs other than the ones explicitly
exposed via a WebExtension API. Only "system add-ons" have that power now.

yes!  I actually often cull tabs from session-restore (vertical list
> ​ ​
> with titles!) or from about:tabs (Tab-stats extension, now broken --
> Glandium!?)
>

​about:tabs is back! If you don't have it go to about:addons and force an
update check through the gear-icon menu. It auto-updated and re-enabled
itself for me sometime in the last week. I missed that one -- my number of
open tabs tripled without the visibility that tool provides (especially
since Tab Groups, the other one I used, is dead).

-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Randell Jesup]

>On Fri, Oct 6, 2017 at 12:57 AM, Lars Hansen  wrote:
>
>> even if I don't exactly remember the ID I'm looking for I can narrow
>> it down to one or two tabs and then hover if I need to.
>>
>> Many other sites also have tabs that can be distinguished
>> from the first few letters - if you can see them.​  (Too many do not.)
>> Indeed now that I have this pref to play with I have set it to 200 and this
>> seems even better.
>
>​I certainly feel your pain wrt bugzilla tabs​, but outside our community's
>unique intense use-case it's not that common amongst release users (see
>stats given earlier about high percentages with < 10 and < 20 tabs).

I don't know about you, but a common case for me is go-to-news-site,
open-N-articles-in-tabs, read-articles (maybe ;-) ).  Probably learned
that in the days of less bandwidth; stuff can pull down in the
background.  Saves a lot of go-back,
wait-for-page-to-load/render/scroll/etc.

For that usage, I need at least a word or so of the title - N tabs
together with the same favicon.  Current width mostly works for this.

I find (perhaps because I'm a mozilla user, and a tab-hoarder) that
Chrome's UI is DREADFUL for anyone with lots of tabs - and probably
intentionally to push users into closing them, since large numbers of
tabs simply doesn't work as well in Chrome as in Firefox.  So mimicing
their behavior is NOT a good idea, IMHO.

I totally hate the favicon-only view I'm seeing now.  it's miserable.
If I were a user, and didn't know about the hidden pref, I'd downgrade,
and if it wasn't fixed soon I'd look for another browser (or some
extension).  That's how bad it is.

That said: there are other solutions possible.  There's the infamous
"Add something to user Preferences".  There's "publish an extension that
lets you fiddle the width" (doable today).  You could put it on the
right-mouse-button on the bar.  etc.  Or... you could do some sort of
apple-dock-like "tabs (in the bar) expand as you move the mouse
over/near them", which allows much better "Find the tab I want" than
narrow tabs, and even better than 110px/etc because you can see more/all
the title without having to wait for a hover to take hold (and you could
see more of the ones near the mouse, probably.

Of course, that's a lot easier said than done. :-)

>Better still would be making vertical tabs a selectable option in
>about:preferences as a common (and unique to Firefox[1]) power-user option
>rather than making us find and install an add-on.

Yes!

>> I feel that the many-tabs use case is treated as a stepchild in
>> Firefox.​
>>
>> Notably the drag-to-reorganize scheme does not work well for many
>> tabs; a tab pane a la what tabgroups had would be superior.
>
>​Completely agree. Even if we don't support "groups"​ of hidden tabs, the
>tableau visualization was great for managing overstuffed windows and
>quickly culling the tabs spawned during some now-complete task or research.

yes!  I actually often cull tabs from session-restore (vertical list
with titles!) or from about:tabs (Tab-stats extension, now broken -- Glandium!?)

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Daniel Veditz]

On Fri, Oct 6, 2017 at 12:57 AM, Lars Hansen  wrote:

> even if I don't exactly remember the
> ​ ​
> ID I'm looking for I can narrow it down to one or two tabs and then hover
> ​ ​
> if I need to.
> ​ ​
> Many other sites also have tabs that can be distinguished
> ​ ​
> from the first few letters - if you can see them.​  (Too many do not.)
> ​ ​
> Indeed now that I have this pref to play with I have set it to 200 and this
> seems even better.
>

​I certainly feel your pain wrt bugzilla tabs​, but outside our community's
unique intense use-case it's not that common amongst release users (see
stats given earlier about high percentages with < 10 and < 20 tabs). If you
like 200px maybe your (our) special case is better served by one of the
sidebar-tabs extensions that show usable context plus a larger number of
tabs at once rather than changing the default to a value that causes the
common user to start scrolling.

Better still would be making vertical tabs a selectable option in
about:preferences as a common (and unique to Firefox[1]) power-user option
rather than making us find and install an add-on.

I feel that the many-tabs use case is treated as a stepchild in
> ​ Firefox.​
>
> Notably the drag-to-reorganize scheme does not work well for many
> tabs; a tab pane a la what tabgroups had would be superior.
>

​Completely agree. Even if we don't support "groups"​ of hidden tabs, the
tableau visualization was great for managing overstuffed windows and
quickly culling the tabs spawned during some now-complete task or research.

-Dan Veditz

​[1] I'll go out on a limb and guess someone's going to say "Opera did it
first".​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Jonathan Kew]

On 06/10/2017 17:05, Boris Zbarsky wrote:

On 10/3/17 5:18 PM, Boris Zbarsky wrote:
So just to make sure I understand the change (and this is a 
theoretical point, because I haven't had a chance to try the change 
yet)... 


OK, now I have had a chance to try it.

When set to the new 50px default, I see 1 letter of title or less (less, 
because the entire second half of the letter is faded out badly).  This 
makes tabs more or less unusable for me.  :(


Agree totally with this. I had seen the beginning of this discussion 
before I updated to a Nightly with the change, so I knew it was coming 
(and what the rationale was), but I was quite shocked at how unusable I 
found the browser with narrow tabs.


No doubt I'd get used to it somehow if there were no way it could be 
changed, but I don't think I'd ever be happy with it. I've reset mine to 
100, though I can see that if I didn't have lots of bugzilla tabs open 
(where I want to see the whole bug number), I might be OK with about 80.


Aside: IMO, a more interesting UI experiment than shrinking the tab 
width would be a built-in option to put a tab-strip on the side of the 
window, instead of across the top. Yes, I know about Tree-Style Tabs and 
similar add-ons, but I tend to run something as close as possible to a 
"vanilla" browser configuration, so that I'm getting a similar 
experience to the majority of our users. If we had "Tabs at the side" 
(or something) in the browser preferences (or in Customize?), I suspect 
a significant number of users might discover and like it, whereas if it 
requires finding an add-on, most people never will.


JK
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Boris Zbarsky]

On 10/3/17 5:18 PM, Boris Zbarsky wrote:
So just to make sure I understand the change (and this is a theoretical 
point, because I haven't had a chance to try the change yet)... 


OK, now I have had a chance to try it.

When set to the new 50px default, I see 1 letter of title or less (less, 
because the entire second half of the letter is faded out badly).  This 
makes tabs more or less unusable for me.  :(


I've ended up setting the preference to 110px.  That seems to work 
pretty well with the tab titles I have hanging around and need to 
disambiguate


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Boris Zbarsky]

On 10/6/17 9:52 AM, Nicolas B. Pierron wrote:
I will add that 91% of the session on release have 12 or fewer tabs, and 
thus would not be concerned at all by these changes.


Do we actually know that?

As I said upthread, at the 100px tab width my tabs start to scroll when 
adding the 9th tab.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Nicolas B. Pierron]

On 10/05/2017 01:34 PM, Chris Hutten-Czapski wrote:

I prefer the old behaviour, but I don't have a strong opinion on the
matter. I think it's because I'm used to tab navigation by keyboard
shortcut more than by mouse. I rearrange tabs so that they're close
together.

For everyone curious about how much of an outlier your subsessions are...
on Nightly 58: https://mzl.la/2ge6Bpk
Over 20% of subsessions have only one tab.
50% of subsessions have 3 or fewer
Over 90% of subsessions have 20 or fewer.
99% of subsessions have 218 or fewer tabs open concurrently.

Of course this is wildly different on other[1] channels: (
Beta 57's 99%ile is at 22[1]
Release 56's 99%ile is at 148, with 94% of subsessions with 20 or fewer
tabs[2]


Thanks Chris for these data,

I will add that 91% of the session on release have 12 or fewer tabs, and 
thus would not be concerned at all by these changes.  So among the 9% 
remaining, 33% of them are using 20 tabs or fewer, and 67% are using more 
than 20 tabs.


So if I read these correctly, the 10% of the nightly users represented here 
and commenting about the 50px being ideal/non-ideal represent 67% the 
release user population which actually concerned by these changes.


For having tried it on a Windows machine, with tons (overflowing even with 
50px) of tabs opened on youtube.  I can confirm that 50px became unusable 
without having to randomly poke at each tab, because only the icon was 
displayed.  80px was enough to distinguish the channels names.



Note: telemetry.mozilla.org is per-subsession aggregation, not per-client,
so clients with more subsessions are weighted more heavily
(pseudoreplication). Just something to keep in mind.

:chutten

[1]: https://mzl.la/2gdB1YP
[2]: https://mzl.la/2gdXftM


On Wed, Oct 4, 2017 at 4:46 PM, Girish Sharma 
wrote:


+1 to 75px.
All the points that I wanted to say about 50px being too small have
already been said by now.

On Thu, Oct 5, 2017 at 1:29 AM, Dirkjan Ochtman 
wrote:


On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths 
wrote:


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?



Like others, I really like ~75 pixels. This allows me to see the first
5-6 characters of the page's title, which I find really helpful in
distinguishing tabs. At 50 pixels, it's really only the favicon, which
seems much less helpful in my usage.

Cheers,

Dirkjan

___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev





--
Girish Sharma
B.Tech(H), Civil Engineering,
Indian Institute of Technology, Kharagpur

___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev





--
Nicolas B. Pierron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Lars Hansen]

On Wed, Oct 4, 2017 at 6:15 PM, Jeff Griffiths 
wrote:

> On Tue, Oct 3, 2017 at 6:33 PM, Brendan Barnwell 
> wrote:
> ...
>
> > The difference between 12 and 24 tabs is meaningless.  My usage
> of
> > Firefox involves large numbers of tabs, frequently exceeding 1000.  This
> > use case is quite manageable with a combination of extensions (e.g., Tab
> > Mix Plus, Tab Groups Manager, BarTab).  But, due to extension breakage,
> it
> > is so poorly supported by post-57 Firefox that I have no intention of
> > upgrading, unless at some future time it becomes possible for extensions
> to
> > again do what they have been able to do for years and which is being
> > deliberately broken by Firefox 57.
> >
> > That's my two cents.
> >
>
>
> Thanks for your feedback.
>
> I'd like to take this opportunity to frame my request to this list a bit
> more precisely. The feedback I am going to find actionable here is, which
> setting value of this preference do you find most useful.
>

​At 100 I can distinguish different bugzilla tabs by bug ID.  At 50 I
cannot.  This feels important to me; even if I don't exactly remember the
ID I'm looking for I can narrow it down to one or two tabs and then hover
if I need to.  Many other sites also have tabs that can be distinguished
from the first few letters - if you can see them.​  (Too many do not.)
Indeed now that I have this pref to play with I have set it to 200 and this
seems even better.


> Off-topic feedback such as commentary on extension deprecation policies
> aren't actionable for me. I don't work on extensions.
>

​I don't know if this is off-topic or not but I'll briefly mention it
anyway: I feel that the many-tabs use case is treated as a stepchild in
Firefox.  Notably the drag-to-reorganize scheme does not work well for many
tabs; a tab pane a la what tabgroups had would be superior.

--lars
  ​

>
> Jeff
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[bruno ais]

Maybe if you use browser.tabs.tabMinWidth = 80 instead, it can make it work
better than 75 because, with 75, it still loses some extra information.

On Fri, Oct 6, 2017 at 2:20 AM, Ehsan Akhgari 
wrote:

> On 10/04/2017 12:43 PM, Jeff Griffiths wrote:
>
>> Om my system ( retina macbook pro ) 70 is starting to look like a better
>> compromise for tab readability.
>>
> I think 70 is better than 50, but I noticed that if a foreground tab
> starts to play audio and we need to show the audio icon alongside the tab
> close icon, the 70px width is actually not enough and the tab pushes its
> width out a bit!  I think we need to consider a minimum of 75px instead.
>
> But still I think this is a serious degradation for existing users who
> have many tabs in terms of the readability of the titles, but we can
> mitigate it by perhaps reducing the padding.  For example, see this
> screenshot:
>
> https://ehsanakhgari.org/wp-content/uploads/2017/10/tabminwi
> dth-narrowpaddings.png
>
> It shows at above browser.tabs.tabMinWidth = 100 and below
> browser.tabs.tabMinWidth = 75 with the paddings in each tab reduced by 13
> pixels.  There is very little reduction to the amount of space available
> for the tab title if we do something like this, I think...
>
> Cheers,
> Ehsan
>
>
>> How I have been testing this:
>>
>>   * change the value to a specific number, say 70
>>   * open enough tabs so that overflow triggers, then close two tabs,
>> then open a tab ( we retain overflow until 2 tabs have been closed! )
>>   * count the number of tabs opened
>>   * open chrome and open that number of tabs
>>   * compare the utility of each browser
>>
>> Jeff
>>
>> On Wed, Oct 4, 2017 at 9:37 AM, Marco Bonardo > > wrote:
>>
>> On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths
>> > wrote:
>> > 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?
>>
>> I prefer being able to see a minimum part of the title, because I very
>> often have multiple tabs open on the same page (many bugzilla, many
>> searchfox, many crash-stats) and now I cannot distinguish them at all.
>> But at the same time, I never liked much the scrolling behavior, at a
>> point that when my tabs start scrolling, I begin a cleaning taks to
>> close some of them.
>> Looks like I'm unhappy in both cases, sorry. If I'd really have to
>> pick, I'd probably would like to see the first 10 chars of the title.
>>
>>
>>
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Gian-Carlo Pascutto]

On 03-10-17 22:36, Jeff Griffiths wrote:
> 2. if you prefer a value for this pref different than 50 or 100, what
> is it? Why?

80 gives about 3.5 to 4.5 characters of context, which seems to be
enough in most cases. 70 is definitely too tiny, 75 is on the edge (I
could probably live with it). 80 may even be an improvement over 100 for
me. There are less sessions where I end up with scroll.

One reason I don't like smaller than 80 is that the click-able area at
some point gets very small, and you're prone to end up with your cursor
directly over the close button when opening a tab. That makes me
uncomfortable.

I tested how Chrome behaves here, and:

1) The target area for closing is smaller, which helps the above issue.
2) If you open enough the tabs the browser UX just completely buggers out!

I think (2) rather reinforces the point in my previous post :-)

As a last point, I generally try very hard to run my browser as vanilla
as possible, to avoid the situation where Firefox developers effectively
run a different browser than what we ship to users. But in this case I
had to change the pref to be able to work effectively.

-- 
GCP
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Gian-Carlo Pascutto]

On 05-10-17 22:46, Daniel Veditz wrote:
> On Thu, Oct 5, 2017 at 1:07 PM, Gian-Carlo Pascutto  wrote:
> 
>> Is it technically difficult to try the technique of starting with 50px,
>> and switching to 100px as soon as 50px wouldn't fit anyway?
> 
> 
> ​Shrinking until they suddenly embiggen and push half your tabs out of
> sight is going to annoy plenty of people. The current behavior where they
> compress to a fixed size and then start scrolling is much more intuitive.

I'm not so sure given that we currently already have this behavior:
because we have to fit the extra scroll indicators and tab list, adding
one tab too much causes the first three to be pushed out of sight. (And
closing it won't recover due to hysteresis)

I'm not advocating to go from tiny to huge. I'm advocating that we don't
end up where we have unusably small tabs AND scroll them.

-- 
GCP
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Ehsan Akhgari]

On 10/04/2017 12:43 PM, Jeff Griffiths wrote:
Om my system ( retina macbook pro ) 70 is starting to look like a 
better compromise for tab readability.
I think 70 is better than 50, but I noticed that if a foreground tab 
starts to play audio and we need to show the audio icon alongside the 
tab close icon, the 70px width is actually not enough and the tab pushes 
its width out a bit!  I think we need to consider a minimum of 75px instead.


But still I think this is a serious degradation for existing users who 
have many tabs in terms of the readability of the titles, but we can 
mitigate it by perhaps reducing the padding.  For example, see this 
screenshot:


https://ehsanakhgari.org/wp-content/uploads/2017/10/tabminwidth-narrowpaddings.png

It shows at above browser.tabs.tabMinWidth = 100 and below 
browser.tabs.tabMinWidth = 75 with the paddings in each tab reduced by 
13 pixels.  There is very little reduction to the amount of space 
available for the tab title if we do something like this, I think...


Cheers,
Ehsan



How I have been testing this:

  * change the value to a specific number, say 70
  * open enough tabs so that overflow triggers, then close two tabs,
then open a tab ( we retain overflow until 2 tabs have been closed! )
  * count the number of tabs opened
  * open chrome and open that number of tabs
  * compare the utility of each browser

Jeff

On Wed, Oct 4, 2017 at 9:37 AM, Marco Bonardo > wrote:


On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths
> wrote:
> 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?

I prefer being able to see a minimum part of the title, because I very
often have multiple tabs open on the same page (many bugzilla, many
searchfox, many crash-stats) and now I cannot distinguish them at all.
But at the same time, I never liked much the scrolling behavior, at a
point that when my tabs start scrolling, I begin a cleaning taks to
close some of them.
Looks like I'm unhappy in both cases, sorry. If I'd really have to
pick, I'd probably would like to see the first 10 chars of the title.




___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Gian-Carlo Pascutto]

On 4/10/2017 18:15, Jeff Griffiths wrote:
> The feedback I am going to find actionable here is, which
> setting value of this preference do you find most useful.

Jeff,

I've read through all the responses here, and I've seen several people
point out the same problem I did: we're getting the worst of both worlds
right now.

You neither get the fixed positioning of infinite tabs (<50px), and you
don't get the readable titles of scrolling tabs (70-100px).

Is it technically difficult to try the technique of starting with 50px,
and switching to 100px as soon as 50px wouldn't fit anyway? Maybe that
ends up not working well in practice, but what we got now isn't going to
make anyone happy either. So it seems worth trying?

-- 
GCP
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Gian-Carlo Pascutto]

On 5/10/2017 19:35, Boris Zbarsky wrote:
> On 10/5/17 1:05 PM, Gian-Carlo Pascutto wrote:
>> [1] I'm sure users that have been conditioned that there exists only a
>> single search engine are going to be confused by the choice that it
>> offers. Maybe we should remove the search box and switch to an Omnibar.
> 
> Um... haven't we?  Current nightlies have only one bar by default.

It was sarcasm - condemned to a footnote so my ranting wouldn't
interfere with the more important main points.

The search box and the ability to use large number of tabs are things I
consider strong competitive advantages of Firefox over Chrome. I'm not
sure what to think about us getting rid of them. (Contrast to throwing
the add-on ecosystem on the fire: there were strong upsides to that and
the advantage had gotten very debatable. I don't think that applies here
though)

My nightmare right now would be that people get so used to Electron
apps' misrendered fonts on Windows that they ask us to copy the
behavior, because they get conditioned that text is supposed to be hard
to read.

Anyway, enough ranting, there's work to do.

-- 
GCP
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Gian-Carlo Pascutto]

On 03-10-17 22:36, Jeff Griffiths wrote:
> We did this based on some early feedback from a few different sources
> that people coming from chrome 

That's rather ironic. I have always thought that one reason why Chrome
uses these uselessly-tiny tabs is to *discourage* users from hoarding a
lot of tabs and thus ballooning the memory usage with one-tab-per-process.

This can be effectively done by making the browser unusable as soon as
you have a lot of tabs, hence, by making them unreadably small and
impossible to click in that case. And now we're copying this behavior
because Chrome users are conditioned to it.

Madness. [1]

> comments: chrome's "infinite tabs visible" approach results in a much
> higher usable/visible tab count in a given window than ours does. 

Visible, yes. Usable, I don't think so!

> 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?

The existing behavior, by miles.

The problem of the new behavior is that I now have a tab strip with long
streaks of identical icons. How am I going to find anything in here?
Click all of them (now much harder, because the click target is half the
size!), wait for the page to load, move on to the next one? The
usability degradation of this is insane. In fact, it makes it pointless
to keep tabs open, as I have to find them via the awesomebar now and I
might as well just re-open the webpages then, the workflow is the same.

Thinking about what could possibly trigger someone to want this
behavior, I'm guessing there's an intermediate zone where you have a few
tabs open, enough that we would start scrolling them off-screen, but
little enough that they still fit in one window with smaller titles. In
that case, hunting for the right tab probably is easier if you don't
have to scroll, especially as the position will stay fixed(!) and the
amount of times you will guess wrong is smaller.

This also implies that changing the min-width to be smaller *and*
keeping the scrolling will get you the worst of both worlds in terms of
usability. If anything, if the amount of tabs increases to the point
where scrolling is required, I see no reason whatsoever not to restore a
sensible min-width at that exact moment.

> 2. if you prefer a value for this pref different than 50 or 100, what
> is it? Why?

Whatever the previous default was is good enough and infinitely better
than what we have now.

[1] I'm sure users that have been conditioned that there exists only a
single search engine are going to be confused by the choice that it
offers. Maybe we should remove the search box and switch to an Omnibar.

-- 
GCP
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Chris Hutten-Czapski]

I prefer the old behaviour, but I don't have a strong opinion on the
matter. I think it's because I'm used to tab navigation by keyboard
shortcut more than by mouse. I rearrange tabs so that they're close
together.

For everyone curious about how much of an outlier your subsessions are...
on Nightly 58: https://mzl.la/2ge6Bpk
Over 20% of subsessions have only one tab.
50% of subsessions have 3 or fewer
Over 90% of subsessions have 20 or fewer.
99% of subsessions have 218 or fewer tabs open concurrently.

Of course this is wildly different on other[1] channels: (
Beta 57's 99%ile is at 22[1]
Release 56's 99%ile is at 148, with 94% of subsessions with 20 or fewer
tabs[2]

Note: telemetry.mozilla.org is per-subsession aggregation, not per-client,
so clients with more subsessions are weighted more heavily
(pseudoreplication). Just something to keep in mind.

:chutten

[1]: https://mzl.la/2gdB1YP
[2]: https://mzl.la/2gdXftM


On Wed, Oct 4, 2017 at 4:46 PM, Girish Sharma 
wrote:

> +1 to 75px.
> All the points that I wanted to say about 50px being too small have
> already been said by now.
>
> On Thu, Oct 5, 2017 at 1:29 AM, Dirkjan Ochtman 
> wrote:
>
>> On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths 
>> wrote:
>>
>>> 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?
>>>
>>
>> Like others, I really like ~75 pixels. This allows me to see the first
>> 5-6 characters of the page's title, which I find really helpful in
>> distinguishing tabs. At 50 pixels, it's really only the favicon, which
>> seems much less helpful in my usage.
>>
>> Cheers,
>>
>> Dirkjan
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
>
> --
> Girish Sharma
> B.Tech(H), Civil Engineering,
> Indian Institute of Technology, Kharagpur
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Girish Sharma]

+1 to 75px.
All the points that I wanted to say about 50px being too small have already
been said by now.

On Thu, Oct 5, 2017 at 1:29 AM, Dirkjan Ochtman  wrote:

> On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths 
> wrote:
>
>> 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?
>>
>
> Like others, I really like ~75 pixels. This allows me to see the first 5-6
> characters of the page's title, which I find really helpful in
> distinguishing tabs. At 50 pixels, it's really only the favicon, which
> seems much less helpful in my usage.
>
> Cheers,
>
> Dirkjan
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>


-- 
Girish Sharma
B.Tech(H), Civil Engineering,
Indian Institute of Technology, Kharagpur
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Axel Hecht]

Am 04.10.17 um 18:43 schrieb Jeff Griffiths:

Om my system ( retina macbook pro ) 70 is starting to look like a better
compromise for tab readability.

How I have been testing this:

- change the value to a specific number, say 70
- open enough tabs so that overflow triggers, then close two tabs, then
open a tab ( we retain overflow until 2 tabs have been closed! )
- count the number of tabs opened
- open chrome and open that number of tabs
- compare the utility of each browser


I tested 70 and 75 (which Aaron suggested), and so far 75 is OK, 70 is 
crossing the border to my tab claustrophobia.


In particular on 50, I had trouble finding the right hit targets to 
select tabs or close them. And 70 still feels close to that, while 75 
for me personally doesn't.


I'll run with 75 for a couple more days.

And yes, the profiles I'm trying this with are mostly tabs on similar 
sites, so the favicons don't provide any practical value.


Axel



Jeff

On Wed, Oct 4, 2017 at 9:37 AM, Marco Bonardo  wrote:


On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths 
wrote:

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?


I prefer being able to see a minimum part of the title, because I very
often have multiple tabs open on the same page (many bugzilla, many
searchfox, many crash-stats) and now I cannot distinguish them at all.
But at the same time, I never liked much the scrolling behavior, at a
point that when my tabs start scrolling, I begin a cleaning taks to
close some of them.
Looks like I'm unhappy in both cases, sorry. If I'd really have to
pick, I'd probably would like to see the first 10 chars of the title.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Dirkjan Ochtman]

On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths 
wrote:

> 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?
>

Like others, I really like ~75 pixels. This allows me to see the first 5-6
characters of the page's title, which I find really helpful in
distinguishing tabs. At 50 pixels, it's really only the favicon, which
seems much less helpful in my usage.

Cheers,

Dirkjan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Felipe G]

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)

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:

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)

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.

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.

my 2 cents
Felipe

On Tue, Oct 3, 2017 at 5:36 PM, Jeff Griffiths 
wrote:

> 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 https://bugzilla.mozilla.org/
> show_bug.cgi?id=1404465
>
> 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] https://hg.mozilla.org/integration/autoland/rev/a75e0386aad8
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[dario . smiles]

Am Mittwoch, 4. Oktober 2017 18:44:04 UTC+2 schrieb Jeff Griffiths:
> Om my system ( retina macbook pro ) 70 is starting to look like a better
> compromise for tab readability.
> 
> How I have been testing this:
> 
>- change the value to a specific number, say 70
>- open enough tabs so that overflow triggers, then close two tabs, then
>open a tab ( we retain overflow until 2 tabs have been closed! )
>- count the number of tabs opened
>- open chrome and open that number of tabs
>- compare the utility of each browser
> 
> Jeff

70 feels like the bare minimum. I think this needs to be an editable setting if 
it is reduced from 100. But I feel like the standard width should not drop 
below 80 to 100 px for usability and comfortability reasons. I guess hardcore 
users who seek this behaviour of ultra-narrow tabs will find the setting.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[dario . smiles]

Am Dienstag, 3. Oktober 2017 22:36:40 UTC+2 schrieb Jeff Griffiths:
> 
> 1. do you prefer the existing behaviour or the new behaviour?

I don't mind being able to change the minimum-width for the tabs, actually I 
like that Firefox is as customizable as it is, but...

> 2. if you prefer a value for this pref different than 50 or 100, what
> is it? Why?

... i efinitely prefer the 100. The 50 px might allow you to see more tabs 
before you have to start scrolling but at a width of just 50 px you can barely 
read the first letters of a tab name meaning that I solely have to go off the 
favicon in combination with the position. Sometimes I have multiple tabs from 
the same page open then I won't be able to tell the difference at all!
 
> 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.

I would say 2 or 3 would be best. I wouldn't rush this and uplift it to 57. 
Let's hear more opinions fist.

> 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.

I'd say let's do that :D

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Sören Hentzschel via dev-platform]

On 10/3/17 10:36 PM, Jeff Griffiths wrote:

1. it reintroduces an old preference 'browser.tabs.tabMinWidth' that
contains a pixel value that controls the minimum width of a tab.


It's nice that there is a preference now!

1. do you prefer the existing behaviour or the new behaviour?


The existing behaviour is really *much* better for me. I have a lot of 
tabs open and with a value of 50 Firefox is not really usable for me. 
There is less (!) than one character (!) visible and it's even more 
worse with the dark tab strip of the Photon default theme and dark 
favicons (including a few Mozilla websites!) because the favicon is 
almost invisible. So there is a nearly invisible favicon in a lot of 
tabs and less than a single character visible in all tabs.


I also know from a few Chrome users that they like the Firefox behaviour 
much more (they use Chrome for different reasons).



2. if you prefer a value for this pref different than 50 or 100, what
is it? Why?


100 is a great value, it works perfect for me. If you want to hear 
another value from me then I say 99. ;)


I tested different values and even with 60 or 70 it's not really usable 
for me. I would say 80 as a minimum, but 100 is better.


But as I already said: it's great that there is a preference. I would 
*not* change the default value (should be 100). But if people prefer 
another value they can change it now.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Jeff Griffiths]

Om my system ( retina macbook pro ) 70 is starting to look like a better
compromise for tab readability.

How I have been testing this:

   - change the value to a specific number, say 70
   - open enough tabs so that overflow triggers, then close two tabs, then
   open a tab ( we retain overflow until 2 tabs have been closed! )
   - count the number of tabs opened
   - open chrome and open that number of tabs
   - compare the utility of each browser

Jeff

On Wed, Oct 4, 2017 at 9:37 AM, Marco Bonardo  wrote:

> On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths 
> wrote:
> > 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?
>
> I prefer being able to see a minimum part of the title, because I very
> often have multiple tabs open on the same page (many bugzilla, many
> searchfox, many crash-stats) and now I cannot distinguish them at all.
> But at the same time, I never liked much the scrolling behavior, at a
> point that when my tabs start scrolling, I begin a cleaning taks to
> close some of them.
> Looks like I'm unhappy in both cases, sorry. If I'd really have to
> pick, I'd probably would like to see the first 10 chars of the title.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Marco Bonardo]

On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths  wrote:
> 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?

I prefer being able to see a minimum part of the title, because I very
often have multiple tabs open on the same page (many bugzilla, many
searchfox, many crash-stats) and now I cannot distinguish them at all.
But at the same time, I never liked much the scrolling behavior, at a
point that when my tabs start scrolling, I begin a cleaning taks to
close some of them.
Looks like I'm unhappy in both cases, sorry. If I'd really have to
pick, I'd probably would like to see the first 10 chars of the title.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Jeff Griffiths]

On Tue, Oct 3, 2017 at 6:33 PM, Brendan Barnwell 
wrote:
...

> The difference between 12 and 24 tabs is meaningless.  My usage of
> Firefox involves large numbers of tabs, frequently exceeding 1000.  This
> use case is quite manageable with a combination of extensions (e.g., Tab
> Mix Plus, Tab Groups Manager, BarTab).  But, due to extension breakage, it
> is so poorly supported by post-57 Firefox that I have no intention of
> upgrading, unless at some future time it becomes possible for extensions to
> again do what they have been able to do for years and which is being
> deliberately broken by Firefox 57.
>
> That's my two cents.
>


Thanks for your feedback.

I'd like to take this opportunity to frame my request to this list a bit
more precisely. The feedback I am going to find actionable here is, which
setting value of this preference do you find most useful.

Off-topic feedback such as commentary on extension deprecation policies
aren't actionable for me. I don't work on extensions.

Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Michael Kazmierczak]

On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths  wrote:

> 1. do you prefer the existing behaviour or the new behaviour?

Definitely the existing behavior in Firefox.

> 2. if you prefer a value for this pref different than 50 or 100, what
> is it? Why?

It should be adjustable in Preferences, so that user can decide
depending on their screensize. Default at 100px.

My two cents,
Michael

On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths  wrote:
> 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1404465
>
> 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] https://hg.mozilla.org/integration/autoland/rev/a75e0386aad8
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Brendan Barnwell]

On 2017-10-03 13:36, Jeff Griffiths wrote:

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 https://bugzilla.mozilla.org/show_bug.cgi?id=1404465

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.


	I prefer the old behavior.  The Chrome behavior is terrible, because 
with too many tabs open, you can't see any of them, ever.  With a 
scrolling tab bar, you can at least see all of them by scrolling.  The 
Chrome behavior is most definitely NOT "infinite tabs visible".  It is 
"infinite tabs invisible".


	But actually I prefer neither.  What I actually prefer is what Tab Mix 
Plus has provided for years but which will disappear in Firefox 57, 
which is a multi-row tab bar that scrolls vertically, not horizontally.


	The difference between 12 and 24 tabs is meaningless.  My usage of 
Firefox involves large numbers of tabs, frequently exceeding 1000.  This 
use case is quite manageable with a combination of extensions (e.g., Tab 
Mix Plus, Tab Groups Manager, BarTab).  But, due to extension breakage, 
it is so poorly supported by post-57 Firefox that I have no intention of 
upgrading, unless at some future time it becomes possible for extensions 
to again do what they have been able to do for years and which is being 
deliberately broken by Firefox 57.


That's my two cents.

--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Jet Villegas]

+1

On Tue, Oct 3, 2017 at 15:00 Chris Peterson  wrote:

> On 2017-10-03 2:18 PM, Boris Zbarsky wrote:
> > Right now, at 60px, I can see 7-10 chars in a tab title.  This is
> > sometimes (but not always) enough for me to make sense of what I'm
> > looking at when the favicon is not helpful.  For example, for bugzilla
> > bugs I can see the whole bug number.
> >
> > In the new setup is sounds like I will see 1-2 chars.  At that point,
> > it's not immediately clear to me that there's any value to not just
> > setting the min-width to "40px" and allowing all the title text to
> > disappear altogether.  There is definite value in not going below the
> > "keep the favicon entirely visible" value, of course.
>
> I think tab bar usability would be much improved if the tab bar's
> drop-down list of full tab titles was always available. This is the "V"
> button that appears to the right of the "+" tab button.
>
> On my machine, the drop-down list button only appears after 15 tabs are
> open, but (as Boris points out) the tabs stopped being identifiable
> before 15 tabs were open.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Chris Peterson]

On 2017-10-03 2:18 PM, Boris Zbarsky wrote:
Right now, at 60px, I can see 7-10 chars in a tab title.  This is 
sometimes (but not always) enough for me to make sense of what I'm 
looking at when the favicon is not helpful.  For example, for bugzilla 
bugs I can see the whole bug number.


In the new setup is sounds like I will see 1-2 chars.  At that point, 
it's not immediately clear to me that there's any value to not just 
setting the min-width to "40px" and allowing all the title text to 
disappear altogether.  There is definite value in not going below the 
"keep the favicon entirely visible" value, of course.


I think tab bar usability would be much improved if the tab bar's 
drop-down list of full tab titles was always available. This is the "V" 
button that appears to the right of the "+" tab button.


On my machine, the drop-down list button only appears after 15 tabs are 
open, but (as Boris points out) the tabs stopped being identifiable 
before 15 tabs were open.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Myk Melez]

Jeff Griffiths wrote:

1. do you prefer the existing behaviour or the new behaviour?

I prefer the new behavior.


2. if you prefer a value for this pref different than 50 or 100, what
is it? Why?
I prefer a value of 0 (i.e. truly infinite tabs, never scrolling), 
because I distinguish tabs by their positions as much as (if not more so 
than) their labels, and showing all tabs fixes their positions, making 
them much easier to find again and click on, even with only a hazy 
recollection of where they are.


(Tabs do move a bit as other tabs are added/removed, but this movement 
is much slighter than that induced by scrolling, and they still stay in 
the same area of the screen.)


Also, when I'm traversing to a far-away tab, especially when using 
keyboard shortcuts, showing all tabs enables me to "see ahead" and 
locate the target tab with my eyes in time to slow down and stop on it 
with my fingers. With scrolling tabs, however, when far-away tabs are 
offscreen, I tend to overshoot the target and have to backtrack.


Back when we introduced scrolling, I set the preference to minimize it. 
Then, when the preference stopped working, I learned to live with 
scrolling tabs. But I still find it cumbersome and would prefer to 
disable tab scrolling.


I recall that Aza Raskin made some similar points back when we 
introduced scrolling. I think this was his blog post on the subject:


http://www.azarask.in/blog/post/firefox_20_tabs_gone_wrong/


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.
I'm actually the common case most of the time. I don't hoard tabs, and I 
close all tabs (except a small set of pinned tabs) after each browsing 
"session", which lasts anywhere from a few minutes to a few hours (or on 
very rare occasions, days). So I don't usually have more than a handful 
of tabs open.


But occasionally I do research that prompts me to open 20-40 tabs and 
then jump back and forth between them (f.e. when shopping for a product 
for which there are many choices, or when investigating a complex 
technical issue in our products). And that's when the tab overflow 
behavior makes a difference.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Boris Zbarsky]

On 10/3/17 4:36 PM, Jeff Griffiths wrote:

2. it sets the default value of the tab to 50, previously this value
was hard-coded at 100.


Jeff,

So just to make sure I understand the change (and this is a theoretical 
point, because I haven't had a chance to try the change yet)...  Right 
now, the min tab width is 100.  This contains the following pieces:


1)  18px of horizontal padding (on the .tab-content).
2)  16px of favicon.
3)   6px of favicon right-margin.
4)  60px of space for the page title.

With the new setup, just looking at the patch, the main thing that 
changes is that the page title space drops from 60px to 10px when enough 
tabs are open, because none of the other values change, right?


Right now, at 60px, I can see 7-10 chars in a tab title.  This is 
sometimes (but not always) enough for me to make sense of what I'm 
looking at when the favicon is not helpful.  For example, for bugzilla 
bugs I can see the whole bug number.


In the new setup is sounds like I will see 1-2 chars.  At that point, 
it's not immediately clear to me that there's any value to not just 
setting the min-width to "40px" and allowing all the title text to 
disappear altogether.  There is definite value in not going below the 
"keep the favicon entirely visible" value, of course.



We looked into this and I generally agree with the
comments: chrome's "infinite tabs visible" approach results in a much
higher usable/visible


I think there's a difference here between "usable" and "visible" 
And yes, I understand that I can just set the pref as needed.



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.


Just fwiw, at the 100px width, tabstrip scrolling kicks in for me at 9 
tabs.  It's possible that most of our users have wider windows than 
mine, of course.


I will definitely try experimenting a bit with this pref to see how 
things behave in practice.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform