Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

[Kris Maglione]

On Wed, Oct 04, 2017 at 12:42:22AM -0400, Boris Zbarsky wrote:

On 10/2/17 9:50 PM, Kris Maglione wrote:
For the pretty simple micro-benchmark below, here are the 
in-document and out-of-document numbers for three runs without the 
subject principal:


Sorry, I should have been clearer: I meant numbers for "inserted into 
the document" and "not inserted into the document".


Well, on the upside, if I hadn't misread you, I wouldn't have 
thought to check the cross-document case (which is pretty 
relevant to subject principal checks), but would have thought to 
check inserted vs. non-inserted, so I think it came out for the 
best :)


I just did a bit of testing with a non-inlined no-op function and it 
looks like the overhead of NeedsSubjectPrincipal is on the order of 
maybe 1-2ns.  Looks like the actual implementation we end up using 
mostly consists of reinterpret_cast, which is nice and fast.  ;) 
There's one memory read from the JSContext to get the compartment, and 
one memory read from the compartment to get the principal; as long a 
those hit cache all is good.


I'd be pretty surprised if we ever manage to get to that point 
without both locations being in the cache. We check compartment 
flags all over the place when JS is running. Maybe just after a 
block of pure JIT code that touched a huge amount of memory...


So, yeah, it doesn't seem like it should be an issue in 
practice.

___
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: Intent to Enable: Automated Static Analysis feedback in MozReview

[Ehsan Akhgari]

On 10/04/2017 03:17 AM, Jan Keromnes wrote:

TL;DR -- We wrote a static analysis bot for MozReview ("clangbot") and it's
about to complain about any patches that would introduce new C/C++ code
defects to Firefox.

This is fantastic to see, thank you for making it happen!
___
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: Intent to Enable: Automated Static Analysis feedback in MozReview

[Boris Zbarsky]

On 10/4/17 10:32 AM, Jan Keromnes wrote:

We've already disabled this "no defects" comment, and are currently
deploying the fix to production, so the bot should stop sending them soon.


Great, thank you!

No need to apologize, by the way.  Bugmail noise happens; thank you for 
moving on it quickly.


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

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

[Jan Keromnes]

> Not sure this is a bug, but...
>
> I got bugmail today from this bug saying that a patch (not mine; just a
bug I was cced on) didn't have any problems.  Can we consider having the
bot add bug noise only when there _is_ a problem?

Indeed this is problematic, and we're very sorry about this. We didn't
anticipate that "no defects" messages would be so noisy, but this does
outweigh the benefits of knowing that static analysis completed without
finding any issues.

We've already disabled this "no defects" comment, and are currently
deploying the fix to production, so the bot should stop sending them soon.

Apologies for the bugmail noise.

On Wed, Oct 4, 2017 at 4:16 PM, Boris Zbarsky  wrote:

> On 10/4/17 3:17 AM, Jan Keromnes wrote:
>
>> Please report any bugs with the bot here: https://bit.ly/2y9N9Vx
>>
>
> Not sure this is a bug, but...
>
> I got bugmail today from this bug saying that a patch (not mine; just a
> bug I was cced on) didn't have any problems.  Can we consider having the
> bot add bug noise only when there _is_ a problem?
>
> -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: Intent to Enable: Automated Static Analysis feedback in MozReview

[Boris Zbarsky]

On 10/4/17 3:17 AM, Jan Keromnes wrote:

Please report any bugs with the bot here: https://bit.ly/2y9N9Vx


Not sure this is a bug, but...

I got bugmail today from this bug saying that a patch (not mine; just a 
bug I was cced on) didn't have any problems.  Can we consider having the 
bot add bug noise only when there _is_ a problem?


-Boris
___
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: Rationalising Linux audio backend support

[Enrico Weigelt, metux IT consult]

On 29.09.2017 19:26, t...@tomsbox.co.uk wrote:

As someone who has had wonderful times with ALSA & headaches with PA it's time 
to say goodbye FireFox.


Maybe we should have a closer look at the PA library API, whether it
could be usable w/o the pa daemon. IOW: have libpulse implementations
that directly call the native APIs (eg. ALSA on Linux or directsound
on windows).

Another idea could be creating a *thin* (!) API layer, that bridges
to backends of the operator's choice. This, of course, should be 
independent of moz and in plain C, so it can be used by many other

projects having the same problem, instead of yet another private layer.


--mtx

___
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: Containers graduation from Test Pilot - we still care about 57+

[Jonathan Kingston]

Also AMO is accessible to 57 users to download from there instead too :)

On Tue, Oct 3, 2017 at 4:09 PM, Andrew McKay  wrote:

> Just to close the loop on this thread, in 57 this will no longer
> disable multi-e10s.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1404098
>
> Thanks for the heads up Ben.
>
> On 27 September 2017 at 10:53, Ben Kelly  wrote:
> > It disables multi-e10s.  Forced to one content process.
> >
> > On Sep 27, 2017 12:58 PM, "Andrew McKay"  wrote:
> >
> > Sorry, it disables e10s even though it has
> > true in the
> > install.rdf? That shouldn't be the case.
> >
> > On 27 September 2017 at 07:14, Ben Kelly  wrote:
> >> On Mon, Sep 25, 2017 at 9:28 AM, Ben Kelly  wrote:
> >>
> >>> Thanks Jonathan.
> >>>
> >>> Also, it seems the link to the web extension version of the container
> >>> addon is broken above.  This one works for me:
> >>>
> >>> https://github.com/mozilla/multi-account-containers/releases/latest
> >>>
> >>
> >> Sorry, I guess this isn't a web extension yet.  Its a legacy addon and
> >> therefore disables multi-e10s.
> >> ___
> >> 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: Intent to Enable: Automated Static Analysis feedback in MozReview

[Sylvestre Ledru]

We do have tooling which analyze changes  after landing  (coverity is
probably the most visible but we have tooling based on Clang tidy too), we
do report some of the issues but it takes time (and we only report defects
which seem critical or easy to fix like dead code).

Now, because of the future end of splinter and the move to phabricator, our
hope is that the vast majority of the commits will use this platform and
benefit from this work. As you can imagine, the hard work is not to push to
a review platform ;)

Cheers
Sylvestre



Le mer. 4 oct. 2017 à 10:11, Nicholas Nethercote  a
écrit :

> This sounds interesting!
>
> But it's not analyzing patches that are not using MozReview. Will those
> patches be analyzed after landing?
>
> Nick
>
> On Wed, Oct 4, 2017 at 6:17 PM, Jan Keromnes  wrote:
>
>> TL;DR -- We wrote a static analysis bot for MozReview ("clangbot") and
>> it's
>> about to complain about any patches that would introduce new C/C++ code
>> defects to Firefox.
>>
>> Please report any bugs with the bot here: https://bit.ly/2y9N9Vx
>>
>> In an effort to improve the quality of Firefox, we want to catch
>> programming errors *before* they even make it into Nightly. To do this, we
>> created a TaskCluster bot that runs clang static analysis on every patch
>> submitted to MozReview. It then quickly reports any code defects directly
>> on MozReview, thus preventing bad patches from landing until all their
>> defects are fixed. Currently, its feedback is posted in about 10 minutes
>> after a patch series is published on MozReview.
>>
>> Here is an example of an automated clangbot review:
>> https://reviewboard.mozilla.org/r/171868/#review190602
>>
>> Our bot relies on three types of clang checkers:
>>
>> - Mozilla specific checkers
>>
> .
>> They
>
>
>> detect incorrect Gecko programming patterns which could lead to bugs or
>> security issues.
>>
>> - Clang-tidy checkers
>>
> . They aim to
>
>
>> suggest better programming practices and to improve memory efficiency and
>> performance.
>>
>> - Clang-analyzer checkers
>>
> . These checks are
>
>
>> more advanced, for example some of them can detect dead code or memory
>> leaks, but as a typical side effect they have false positives. Because of
>> that, we have disabled them for now, but will enable some of them in the
>> near future.
>>
>> The checkers that are currently enabled rarely generate false positives,
>> and you can find the complete list of enabled checkers
>>
> <
>> https://hg.mozilla.org/mozilla-central/file/tip/tools/clang-tidy/config.yaml
>> >
>
>
>> in the tree. You can also run them on your own code with:
>>
>> > ./mach static-analysis check path/to/file.cpp
>>
>> This is only the first step. Next, we would like to catch more classes of
>> programming errors.
>>
>> - If you know incorrect Gecko programming patterns which could be detected
>> by static analysis, please send an email to release-m...@mozilla.com or
>> report a bug in the Rewriting and Analysis
>>
> <
>> https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Rewriting%20and%20Analysis
>> >
>
>
>> component.
>>
>> - In parallel, if you see any additional clang-tidy checkers
>>
>  which could be
>
>
>> valuable for our code base if enabled, please let us know so that we can
>> evaluate them.
>>
>> - Finally, we are looking into posting reviews to Phabricator in the near
>> future as well.
>>
>> Feedback, questions or suggestions welcome.
>>
>> Thanks!
>>
>> Andi, Bastien, Jan and Sylvestre
>>
> ___
>> 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: Intent to Enable: Automated Static Analysis feedback in MozReview

[Jan Keromnes]

> But it's not analyzing patches that are not using MozReview. Will those
patches be analyzed after landing?

Indeed, our bot doesn't run on patches that are attached to Bugzilla
(Splinter reviews) or directly landed.

However, I believe that the Mozilla checkers we use are also run on Try,
and should cause any offending patches to be backed out.

The purpose of our bot is to catch defects at review time, in order to
reduce the number of new defects getting into the tree, but we're also
working on fixing all defects that are currently present in our code base,
which is a much larger project.

> Sounds awesome! I tried this locally to see what it would say about a
random(ish) file in the tree, but it ended with the message:
>
>  0:42.99 Could not find artifacts for a toolchain build named
`macosx64-clang-tidy`
>
> which sounds like something's missing. It would be nice if it could
automatically obtain the required tools, or at least offer a hint as to
what I should do to set up a suitable environment.

Thank you for trying! Nothing is missing, this is actually a regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1405570

We were able to work around the bug (we've triggered a manual build, so the
command should work again by now) and we're looking into fixing it as soon
as possible.


On Wed, Oct 4, 2017 at 10:11 AM, Nicholas Nethercote  wrote:

> This sounds interesting!
>
> But it's not analyzing patches that are not using MozReview. Will those
> patches be analyzed after landing?
>
> Nick
>
> On Wed, Oct 4, 2017 at 6:17 PM, Jan Keromnes  wrote:
>
>> TL;DR -- We wrote a static analysis bot for MozReview ("clangbot") and
>> it's
>> about to complain about any patches that would introduce new C/C++ code
>> defects to Firefox.
>>
>> Please report any bugs with the bot here: https://bit.ly/2y9N9Vx
>>
>> In an effort to improve the quality of Firefox, we want to catch
>> programming errors *before* they even make it into Nightly. To do this, we
>> created a TaskCluster bot that runs clang static analysis on every patch
>> submitted to MozReview. It then quickly reports any code defects directly
>> on MozReview, thus preventing bad patches from landing until all their
>> defects are fixed. Currently, its feedback is posted in about 10 minutes
>> after a patch series is published on MozReview.
>>
>> Here is an example of an automated clangbot review:
>> https://reviewboard.mozilla.org/r/171868/#review190602
>>
>> Our bot relies on three types of clang checkers:
>>
>> - Mozilla specific checkers
>> .
>> They
>> detect incorrect Gecko programming patterns which could lead to bugs or
>> security issues.
>>
>> - Clang-tidy checkers
>> . They aim to
>> suggest better programming practices and to improve memory efficiency and
>> performance.
>>
>> - Clang-analyzer checkers
>> . These checks are
>> more advanced, for example some of them can detect dead code or memory
>> leaks, but as a typical side effect they have false positives. Because of
>> that, we have disabled them for now, but will enable some of them in the
>> near future.
>>
>> The checkers that are currently enabled rarely generate false positives,
>> and you can find the complete list of enabled checkers
>> > clang-tidy/config.yaml>
>> in the tree. You can also run them on your own code with:
>>
>> > ./mach static-analysis check path/to/file.cpp
>>
>> This is only the first step. Next, we would like to catch more classes of
>> programming errors.
>>
>> - If you know incorrect Gecko programming patterns which could be detected
>> by static analysis, please send an email to release-m...@mozilla.com or
>> report a bug in the Rewriting and Analysis
>> > ponent=Rewriting%20and%20Analysis>
>> component.
>>
>> - In parallel, if you see any additional clang-tidy checkers
>>  which could be
>> valuable for our code base if enabled, please let us know so that we can
>> evaluate them.
>>
>> - Finally, we are looking into posting reviews to Phabricator in the near
>> future as well.
>>
>> Feedback, questions or suggestions welcome.
>>
>> Thanks!
>>
>> Andi, Bastien, Jan and Sylvestre
>> ___
>> 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: Intent to Enable: Automated Static Analysis feedback in MozReview

[Jonathan Kew]

On 04/10/2017 09:17, Jan Keromnes wrote:

You can also run them on your own code with:


./mach static-analysis check path/to/file.cpp


Sounds awesome! I tried this locally to see what it would say about a 
random(ish) file in the tree, but it ended with the message:


 0:42.99 Could not find artifacts for a toolchain build named 
`macosx64-clang-tidy`


which sounds like something's missing. It would be nice if it could 
automatically obtain the required tools, or at least offer a hint as to 
what I should do to set up a suitable environment.


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

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

[Nicholas Nethercote]

This sounds interesting!

But it's not analyzing patches that are not using MozReview. Will those
patches be analyzed after landing?

Nick

On Wed, Oct 4, 2017 at 6:17 PM, Jan Keromnes  wrote:

> TL;DR -- We wrote a static analysis bot for MozReview ("clangbot") and it's
> about to complain about any patches that would introduce new C/C++ code
> defects to Firefox.
>
> Please report any bugs with the bot here: https://bit.ly/2y9N9Vx
>
> In an effort to improve the quality of Firefox, we want to catch
> programming errors *before* they even make it into Nightly. To do this, we
> created a TaskCluster bot that runs clang static analysis on every patch
> submitted to MozReview. It then quickly reports any code defects directly
> on MozReview, thus preventing bad patches from landing until all their
> defects are fixed. Currently, its feedback is posted in about 10 minutes
> after a patch series is published on MozReview.
>
> Here is an example of an automated clangbot review:
> https://reviewboard.mozilla.org/r/171868/#review190602
>
> Our bot relies on three types of clang checkers:
>
> - Mozilla specific checkers
> .
> They
> detect incorrect Gecko programming patterns which could lead to bugs or
> security issues.
>
> - Clang-tidy checkers
> . They aim to
> suggest better programming practices and to improve memory efficiency and
> performance.
>
> - Clang-analyzer checkers
> . These checks are
> more advanced, for example some of them can detect dead code or memory
> leaks, but as a typical side effect they have false positives. Because of
> that, we have disabled them for now, but will enable some of them in the
> near future.
>
> The checkers that are currently enabled rarely generate false positives,
> and you can find the complete list of enabled checkers
>  tools/clang-tidy/config.yaml>
> in the tree. You can also run them on your own code with:
>
> > ./mach static-analysis check path/to/file.cpp
>
> This is only the first step. Next, we would like to catch more classes of
> programming errors.
>
> - If you know incorrect Gecko programming patterns which could be detected
> by static analysis, please send an email to release-m...@mozilla.com or
> report a bug in the Rewriting and Analysis
>  component=Rewriting%20and%20Analysis>
> component.
>
> - In parallel, if you see any additional clang-tidy checkers
>  which could be
> valuable for our code base if enabled, please let us know so that we can
> evaluate them.
>
> - Finally, we are looking into posting reviews to Phabricator in the near
> future as well.
>
> Feedback, questions or suggestions welcome.
>
> Thanks!
>
> Andi, Bastien, Jan and Sylvestre
> ___
> 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

Intent to Enable: Automated Static Analysis feedback in MozReview

[Jan Keromnes]

TL;DR -- We wrote a static analysis bot for MozReview ("clangbot") and it's
about to complain about any patches that would introduce new C/C++ code
defects to Firefox.

Please report any bugs with the bot here: https://bit.ly/2y9N9Vx

In an effort to improve the quality of Firefox, we want to catch
programming errors *before* they even make it into Nightly. To do this, we
created a TaskCluster bot that runs clang static analysis on every patch
submitted to MozReview. It then quickly reports any code defects directly
on MozReview, thus preventing bad patches from landing until all their
defects are fixed. Currently, its feedback is posted in about 10 minutes
after a patch series is published on MozReview.

Here is an example of an automated clangbot review:
https://reviewboard.mozilla.org/r/171868/#review190602

Our bot relies on three types of clang checkers:

- Mozilla specific checkers
. They
detect incorrect Gecko programming patterns which could lead to bugs or
security issues.

- Clang-tidy checkers
. They aim to
suggest better programming practices and to improve memory efficiency and
performance.

- Clang-analyzer checkers
. These checks are
more advanced, for example some of them can detect dead code or memory
leaks, but as a typical side effect they have false positives. Because of
that, we have disabled them for now, but will enable some of them in the
near future.

The checkers that are currently enabled rarely generate false positives,
and you can find the complete list of enabled checkers

in the tree. You can also run them on your own code with:

> ./mach static-analysis check path/to/file.cpp

This is only the first step. Next, we would like to catch more classes of
programming errors.

- If you know incorrect Gecko programming patterns which could be detected
by static analysis, please send an email to release-m...@mozilla.com or
report a bug in the Rewriting and Analysis

component.

- In parallel, if you see any additional clang-tidy checkers
 which could be
valuable for our code base if enabled, please let us know so that we can
evaluate them.

- Finally, we are looking into posting reviews to Phabricator in the near
future as well.

Feedback, questions or suggestions welcome.

Thanks!

Andi, Bastien, Jan and Sylvestre
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform