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 nu
+1 to 75px.
All the points that I wanted to say about 50px being too small have already
been said by now.
On Thu, Oct 5, 2017 at 1:29 AM, Dirkjan Ochtman wrote:
> On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths
> wrote:
>
>> 1. do you prefer the existing behaviour or the new behaviour?
>> 2. if
Am 04.10.17 um 18:43 schrieb Jeff Griffiths:
Om my system ( retina macbook pro ) 70 is starting to look like a better
compromise for tab readability.
How I have been testing this:
- change the value to a specific number, say 70
- open enough tabs so that overflow triggers, then close tw
On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths
wrote:
> 1. do you prefer the existing behaviour or the new behaviour?
> 2. if you prefer a value for this pref different than 50 or 100, what
> is it? Why?
>
Like others, I really like ~75 pixels. This allows me to see the first 5-6
characters of
I like having this option back, as I know this was a feature that a lot of
people liked in the past. (even though I'm personally ok with the 100px
width)
I've been trying to use the new default (50px) for a couple of hours, and
it felt surprisingly unusable, in a way that I couldn't quite figure
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!
__
Am Mittwoch, 4. Oktober 2017 18:44:04 UTC+2 schrieb Jeff Griffiths:
> Om my system ( retina macbook pro ) 70 is starting to look like a better
> compromise for tab readability.
>
> How I have been testing this:
>
>- change the value to a specific number, say 70
>- open enough tabs so that
Am Dienstag, 3. Oktober 2017 22:36:40 UTC+2 schrieb Jeff Griffiths:
>
> 1. do you prefer the existing behaviour or the new behaviour?
I don't mind being able to change the minimum-width for the tabs, actually I
like that Firefox is as customizable as it is, but...
> 2. if you prefer a value for
On 10/3/17 10:36 PM, Jeff Griffiths wrote:
1. it reintroduces an old preference 'browser.tabs.tabMinWidth' that
contains a pixel value that controls the minimum width of a tab.
It's nice that there is a preference now!
1. do you prefer the existing behaviour or the new behaviour?
The existin
Om my system ( retina macbook pro ) 70 is starting to look like a better
compromise for tab readability.
How I have been testing this:
- change the value to a specific number, say 70
- open enough tabs so that overflow triggers, then close two tabs, then
open a tab ( we retain overflow u
On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths wrote:
> 1. do you prefer the existing behaviour or the new behaviour?
> 2. if you prefer a value for this pref different than 50 or 100, what
> is it? Why?
I prefer being able to see a minimum part of the title, because I very
often have multiple t
On Tue, Oct 3, 2017 at 6:33 PM, Brendan Barnwell
wrote:
...
> The difference between 12 and 24 tabs is meaningless. My usage of
> Firefox involves large numbers of tabs, frequently exceeding 1000. This
> use case is quite manageable with a combination of extensions (e.g., Tab
> Mix Plus
On 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 quickl
> 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 di
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
On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths wrote:
> 1. do you prefer the existing behaviour or the new behaviour?
Definitely the existing behavior in Firefox.
> 2. if you prefer a value for this pref different than 50 or 100, what
> is it? Why?
It should be adjustable in Preferences, so t
On 2017-10-03 13:36, Jeff Griffiths wrote:
Hi!
tl;dr we changed the default pixel value at which we overflow tabs,
and I want your feedback.
We just added a change to m-c[1] that does to things:
1. it reintroduces an old preference 'browser.tabs.tabMinWidth' that
contains a pixel value that co
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
+1
On Tue, Oct 3, 2017 at 15:00 Chris Peterson wrote:
> On 2017-10-03 2:18 PM, Boris Zbarsky wrote:
> > Right now, at 60px, I can see 7-10 chars in a tab title. This is
> > sometimes (but not always) enough for me to make sense of what I'm
> > looking at when the favicon is not helpful. For ex
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
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
> 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 sho
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 art
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 a
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
25 matches
Mail list logo
