Changes to tab min-width

[Jeff Griffiths]

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

[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

[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: recording use counters for web features

[Jeff Griffiths]

This looks like it will be amazing. I would like to talk about
expanding css coverage as much as possible, as a followup to the
initial work.

On Thu, Aug 20, 2015 at 9:38 AM, Nathan Froyd  wrote:
> [Responding to the list this time...]
>
> On Thu, Aug 20, 2015 at 4:05 AM, Patrick Brosset 
> wrote:
>
>> [Cc dev-developer-tools because this is relevant to devtools]
>>
>> On Wed, Aug 19, 2015 at 5:35 PM, Nathan Froyd  wrote:
>>>
>>> - CSS property
>>>
>>
>> Awesome! This is going to be useful for bug 1168246
>>  that aims at being
>> smart about ordering CSS properties when showing the auto-complete list in
>> the inspector.
>>
>
> It's worth noting that we don't collect information on very many CSS
> properties (just enough to be able to write useful tests, at the moment...).
>
>
>> These statistics are reported through Telemetry.
>>>
>>
>> Could you give details about this please? How will we be able to access
>> this data?
>>
>
> They are regular histograms, so you ought to be able to access them through
> the Telemetry dashboards at http://telemetry.mozilla.org/ .
>
> That being said, they are not available there yet, possibly due to the
> slightly unorthodox way we generate the histograms.  So you may have to
> wait a little while we we get that sorted out.
>
> I have plans to write a custom dashboard for the use counter histograms, so
> that you can see them in the more understandable form "X% of documents use
> $FEATURE"...but one thing at a time. :)
>
> -Nathan
>
> On Thu, Aug 20, 2015 at 4:05 AM, Patrick Brosset 
> wrote:
>
>> [Cc dev-developer-tools because this is relevant to devtools]
>>
>> On Wed, Aug 19, 2015 at 5:35 PM, Nathan Froyd  wrote:
>>
>>> Bug 968923, "Implement some equivalent of Chrome's use counters", has
>>> landed on mozilla-central.  We are now able to report statistics on
>>> whether
>>> individual documents use a given:
>>>
>>> - WebIDL method
>>> - WebIDL attribute (getters and setters reported separately)
>>> - CSS property
>>>
>>
>> Awesome! This is going to be useful for bug 1168246
>>  that aims at being
>> smart about ordering CSS properties when showing the auto-complete list in
>> the inspector.
>>
>>
>>> - operation listed in dom/base/nsDeprecatedOperationList.h
>>>
>>> These statistics are reported through Telemetry.
>>>
>>
>> Could you give details about this please? How will we be able to access
>> this data?
>>
>>
>>>
>>> Deprecated operations are handled automatically.  CSS properties require
>>> modifying dom/base/UseCounters.conf.  WebIDL methods and attributes
>>> require
>>> modifying dom/base/UseCounters.conf and adding a [UseCounter] attribute to
>>> the appropriate entity in the corresponding WebIDL file.  (Bug 1195959
>>> tracks eliminating the WebIDL file modification, if you are curious.)
>>>
>>> Please see dom/base/UseCounters.conf for more information, and come find
>>> people in #content if you have questions.
>>>
>>> Thanks,
>>> -Nathan
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
> ___
> dev-developer-tools mailing list
> dev-developer-to...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

E10S and Dom Inspector

[Jeff Griffiths]

( re-posting this from firefox-dev at dcamp's suggestion, sorry if this
feels
like a duplicate thread to you )

The e10s team looked at bug 1078121[1] this morning and asked how
concerned I am about it. I responded in comment 7 ( link below ) and I
*think* my workarounds are reasonable, however I want to ensure that
people are aware of DOM Inspector's limitations wrt e10s and also get
feedback from the Firefox development community on how important DOM
Inspector is to them.

If you're using DOM Inspector as an indispensable part of your
workflow developing for Firefox Desktop I'd like to hear about your
use case and in particular what is lacking in the Browser Toolbox. No
need to be polite, but please provide links to bugs if you have them.

Aside: there is a tracking bug for improvements to the Browser Toolbox [2]

Jeff

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1078121#c7
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1090423
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Moving DevTools to top level /devtools directory

[Jeff Griffiths]

On Thu, Jul 23, 2015 at 11:43 AM, J. Ryan Stinnett  wrote:
> On Thu, Jul 23, 2015 at 8:11 AM, Paul Rouget  wrote:
>> I guess by moving things to /devtools/, you also want to update the
>> URLs to chrome://devtools/content.
>> So then, we can compile and open the devtools with non-firefox builds
>> (thunderbird, b2g, seamonkey, ...).
>> But if the devtools include browser code, this won't work. For
>> example, we import
>> chrome://browser/content/utilityOverlay.js, which is Firefox only.
>
> The main goal of this work is around making the DevTools codebase more
> approachable for contributors.
>
> We're not explicitly setting out to make reusing the front end easier
> from non-Firefox, but certainly moving out of /browser is one nudge in
> the right direction down that path.
>
> I'm guessing we'll still have some browser dependencies for the
> moment, but I'll take a look at this as I work on the file moves.

That's correct. The use case is, again:

* git clone devtools
* ./nightly
* point devtools source directory to the git clone
* hack on firefox devtools in Nightly, reloading the source as need be

Anything else can wait until later as Ryan suggested.

Paul: are there things you want for graphene?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform