Hi everyone,
Here's the list of new issues found and filed by the Desktop Release QA
Team last week, *October 2 - October* *6* (week 40).
Additional details on the team's priorities last week, as well as the
plans for the current week are available at:
https://public.etherpad-mozilla.org
As part of our work with Tor, we’ve been working on getting a MinGW-based
build of Windows into TaskCluster. Tor is currently using ESR releases, and
every ESR they have to go through a large amount of work to get the build
working under MinGW again; by continually building (and testing) that build
On Mon, Oct 9, 2017 at 1:32 PM, Kyle Huey wrote:
>
> You couldn't get to mozilla::Atom?
>
See https://bugzilla.mozilla.org/show_bug.cgi?id=1400460#c2.
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo
Awesome!
You couldn't get to mozilla::Atom?
- Kyle
On Oct 8, 2017 7:27 PM, "Nicholas Nethercote"
wrote:
> Greetings,
>
> I have been deCOMtaminating nsIAtom over the past two months:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1392883.
>
> A big step that landed over a week ago was the devi
Greetings,
I have been deCOMtaminating nsIAtom over the past two months:
https://bugzilla.mozilla.org/show_bug.cgi?id=1392883.
A big step that landed over a week ago was the devirtualization of nsIAtom,
which means it is no longer a subclass of nsISupports:
https://bugzilla.mozilla.org/show_bug.c
On 10/8/17 8:22 PM, Matt Woodrow wrote:
We're planning to land into mozilla-central in the next week or two, and
then enable it by default for Nightly within a week or two of that.
This is awesome news. Big thanks to everyone who worked on this!
-Boris
Hello all,
We're planning on landing the code for retaining display lists in 58,
behind the pref layout.display.list.retain.
This is a rather large reworking of how we paint, and was designed to
address telemetry results [1] showing that display list building was
consuming considerable amo
If you introduced the setting, I think it would increase it up to 150px to be
able to see more tab title. Particularly when I have a lot of tabs from the
same site open, it could help.
At this moment I have 45 tabs open in Firefox, and 25 in Firefox Developer
edition. Tabs start scrolling for
In my opinion, the important thing is that this is not about disabling
scrolling behaviour altogether. This will not affect users with <10 tabs, it
will possibly help Chrome users with 10-20 tabs, and it will destroy both use
cases for users with >20 tabs because the tabs will be unreadable AND
Hi!
I forgot to mention this issue, thank you for bringing it up.
Background throttling is disabled whenever something that is
considered real time, like audio, or could potentially time out, like
web sockets, is present on he page, including iframes.
To both prove to myself that these mechanisms
On Tuesday, October 3, 2017 at 4:36:40 PM UTC-4, 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?
1. Prefer old behavior, but can understand the desire for the new behavior
>> 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 b
> 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
Hi, just a (power?) user input here, my subjective POV.
In fact I was a little frightened when that min-width changed in Nightly. I
liked very much the old behaviour, to see only a fraction of opened tabs (I'm
nearly always in the overflow territory anyway), disliked Chrome for that
"compressio
14 matches
Mail list logo
