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://l
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
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 theoreti
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
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.tabMin
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
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
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 chang
I've always found the tabs scrolling off the side thing to be really
disorienting, so I'm glad FF is trying to diminish or remove it. It's one of
the big reasons I use sidebar tabs.
Here's my 2¢:
1. I think overflow tabs should stack rows so you can always see the extra
tabs. This is how most
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
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
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
>> 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 b
> 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
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
"compressio
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
On Sat, Oct 7, 2017 at 9:40 AM, Mike Hommey wrote:
> Side note: it's sad that side-bar based tab addons now have to waste a
> large portion of vertical space because of the (large) side-bar header.
> Plus, they can't push the toolbar like they used to, taking the whole
> height of the window.
>
On Fri, Oct 06, 2017 at 05:40:13PM +0100, Jonathan Kew wrote:
> 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
> > > ye
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
>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 t
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 -
I settled on 110px as well for the same reason.
-e
On Fri, Oct 6, 2017 at 9:05 AM, 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)...
>>
>
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,
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,
bec
On Fri, Oct 6, 2017 at 3:52 PM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> 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. So among the 9%
> remaining, 33% of them are using 20 tabs or fewer, and 6
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.
-
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 ho
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
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
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 m
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
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 c
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 plent
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
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 a
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
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 t
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 Nightl
+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
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 tw
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
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
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
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
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 existin
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 u
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 t
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
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 t
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 co
+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 ex
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 n
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 the
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
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 set
55 matches
Mail list logo
