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: C++ function that the optimizer won't eliminate

[Botond Ballo]

Not immediately useful to us, but there is a C++ standards proposal in
the works for a standard library function along these lines:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0412r0.html

Cheers,
Botond
___
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: C++ function that the optimizer won't eliminate

[David Major]

I bet Google Benchmark will have what you want.

As a first guess, maybe this?
https://github.com/google/benchmark/blob/master/include/benchmark/benchmark.h#L297

(And if godbolt says they are wrong, please send them a PR :))


On Fri, Oct 6, 2017 at 9:16 AM, Gabriele Svelto  wrote:

> On 06/10/2017 11:00, Henri Sivonen wrote:
> > Do we already have a C++ analog of Rust's test::black_box() function?
> > I.e. a function that just passes through a value but taints it in such
> > a way that the optimizer can't figure out that there are no side
> > effects. (For the purpose of ensuring that the compiler can't
> > eliminate computation that's being benchmarked.)
> >
> > If we don't have one, how should one be written so that it works in
> > GCC, clang and MSVC?
> >
> > It's surprisingly hard to find an answer to this on Google or
> > StackOverflow, and experimentation on godbolt.org suggests that easy
> > answers that are found are also wrong.
> >
> > Specifically, this isn't the answer for GCC:
> > void* black_box(void* foo) {
> >   asm ("":"=r" (foo): "r" (foo):"memory");
> >   return foo;
> > }
>
> IIUC what you are looking for is the '+' constraint which implies the
> parameter is both read and written in the asm statement, e.g.:
>
> void* black_box(void* foo) {
>   asm ("":"+r" (foo): "r" (foo):"memory");
>   return foo;
> }
>
>  Gabriele
>
>
> ___
> 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

[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: C++ function that the optimizer won't eliminate

[Gabriele Svelto]

On 06/10/2017 11:00, Henri Sivonen wrote:
> Do we already have a C++ analog of Rust's test::black_box() function?
> I.e. a function that just passes through a value but taints it in such
> a way that the optimizer can't figure out that there are no side
> effects. (For the purpose of ensuring that the compiler can't
> eliminate computation that's being benchmarked.)
> 
> If we don't have one, how should one be written so that it works in
> GCC, clang and MSVC?
> 
> It's surprisingly hard to find an answer to this on Google or
> StackOverflow, and experimentation on godbolt.org suggests that easy
> answers that are found are also wrong.
> 
> Specifically, this isn't the answer for GCC:
> void* black_box(void* foo) {
>   asm ("":"=r" (foo): "r" (foo):"memory");
>   return foo;
> }

IIUC what you are looking for is the '+' constraint which implies the
parameter is both read and written in the asm statement, e.g.:

void* black_box(void* foo) {
  asm ("":"+r" (foo): "r" (foo):"memory");
  return foo;
}

 Gabriele



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ function that the optimizer won't eliminate

[Nathan Froyd]

On Fri, Oct 6, 2017 at 5:00 AM, Henri Sivonen  wrote:
> Do we already have a C++ analog of Rust's test::black_box() function?

We do not.

> Specifically, this isn't the answer for GCC:
> void* black_box(void* foo) {
>   asm ("":"=r" (foo): "r" (foo):"memory");
>   return foo;
> }

Can you provide a slightly larger example testcase (links to
godbolt.org would be excellent) that actually uses this, so we can see
what the compiler is doing?

I think it's customary to make these sorts of asms `volatile asm` to
tell the compiler to not touch it.  I don't know how to write one for
MSVC, but I think a small variant of the above should work for GCC.

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

Re: C++ function that the optimizer won't eliminate

[Boris Zbarsky]

On 10/6/17 5:00 AM, Henri Sivonen wrote:

If we don't have one, how should one be written so that it works in
GCC, clang and MSVC?


Are you OK with it being restricted to a single thread?  If so, would 
something like this work?


  mutable void* taint;
  void* black_box(void* foo) {
taint = foo;
return taint;
  }

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