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

[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 <mbona...@mozilla.com> wrote:

> On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths <jgriffi...@mozilla.com>
> 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

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

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 jry...@gmail.com wrote:
 On Thu, Jul 23, 2015 at 8:11 AM, Paul Rouget p...@mozilla.com 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