MinGW Target on TaskCluster

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

Re: nsIAtom has been deCOMtaminated and is now called nsAtom

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

Re: nsIAtom has been deCOMtaminated and is now called nsAtom

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

nsIAtom has been deCOMtaminated and is now called nsAtom

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:

Re: Intent to ship: Retained Display Lists

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

Intent to ship: Retained Display Lists

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

Re: Changes to tab min-width

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

Re: Changes to tab min-width

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

Re: Changes to tab min-width

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

Re: Changes to tab min-width

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

Re: Changes to tab min-width

> 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. > >

Re: Changes to tab min-width

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