Intent to ship: Frames timing functions

As of Firefox 55, I intend to land the patches of Frames timing functions in Bug 1248340 . Currently, we decide not to add a pref for that, so we will ship it directly. In this bug, we also contribute the tests into web-platform-test*,

Re: All the processes

On Tue, Mar 7, 2017 at 11:27 AM, wrote: > > Intuitively I don't grasp how each content process can add that much more memory that it would become a "major problem" jumping from 4 to 8 Simple: lots of stuff gets duplicated in each process. Efforts have been made to share

Re: All the processes

On Mon, Mar 6, 2017 at 7:08 PM, Eric Rahm wrote: > I assume WebRenderer will have it's own process, but maybe that just gets > lumped in with the GPU process. WebRender will live in the GPU process, if there is one. The UI process otherwise. Cheers, kats

Intent to deprecate - command line paremeter "uiLocale"

Deep in the dungeons of Mount nsChromeRegistryChrome[0], lies an ancient line of code that in the Days Of Old allowed knowledgeable spellcasters to select the locale of the user interface straight from the command line - "uiLocale"[1]. Since then, many things have changed, and folks forgot

Re: All the processes

On Mon, Mar 6, 2017 at 4:45 PM, Eric Rahm wrote: > I'd suggest looking at the memory overhead of Chrome's individual processes > as compared to ours, it's pretty impressive. My blog posts on our own e10s > memory usage [1] and comparison to other browsers [2] have further

Re: All the processes

On Mon, Mar 6, 2017 at 4:27 PM, wrote: > Just about the "4 good, 8 bad" part, it seems quite arbitrary -- Wouldn't > that be hardware-dependent? > I would think users with "only" 1GB may have different needs and > expectations from users with 16+GB. > It's more about

Re: All the processes

Just about the "4 good, 8 bad" part, it seems quite arbitrary -- Wouldn't that be hardware-dependent? I would think users with "only" 1GB may have different needs and expectations from users with 16+GB. Intuitively I don't grasp how each content process can add that much more memory that it

Re: All the processes

It should be pretty easy to measure at a high level with ATSY [1], but I agree coordination on overall memory requirements before adding new processes would be useful. For more detailed breakdowns of memory usage we can depend on about:memory reports for content processes, we added support for

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

I filed bug 1344936 [1] for the archive.m.o issue and updated mozdownload's "add support for taskcluster" bug [2]. -e [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1344936 [2] https://github.com/mozilla/mozdownload/issues/365 On Mon, Mar 6, 2017 at 1:33 PM, Henrik Skupin

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

On 3/6/17 5:29 PM, Mike Hommey wrote: You can get the builds through the taskcluster index. Does that have the same lifetime guarantees as archive.mozilla.org? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

On 3/6/17 4:29 PM, Kartikaya Gupta wrote: It looks like it's just the Linux builds that are no longer there. I'm guessing this has to do with them being on TaskCluster rather than BuildBot. That sounds like a TaskCluster bug we should just fix, then populate archive.mozilla.org with the

Re: All the processes

On Tue, Mar 7, 2017 at 9:22 AM, Ben Kelly wrote: > These measurements are for full content processes. Many of the processes > in the above do not need all the chrome script we load in content processes > today. > That's good to know. But it would still be good to get

Re: All the processes

On Mon, Mar 6, 2017 at 2:22 PM, Ben Kelly wrote: > On Mon, Mar 6, 2017 at 5:12 PM, Nicholas Nethercote < > n.netherc...@gmail.com> > wrote: > > > Now for the reason I raised this: the major downside of using multiple > > processes is that it increases memory usage. Recent-ish

Re: All the processes

On Tue, Mar 07, 2017 at 09:12:55AM +1100, Nicholas Nethercote wrote: Now for the reason I raised this: the major downside of using multiple processes is that it increases memory usage. Recent-ish measurements showed that for e10s-multi we could probably go up to 4 content processes without

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

On Mon, Mar 06, 2017 at 01:17:02PM -0800, Eric Rahm wrote: > I'm unaware of a bug for this decision, but https://archive.mozilla.org > stopped adding tinderbox builds back on January 18th. Wild guess: that's when buildbot builds were turned off. You can get the builds through the taskcluster

Re: All the processes

On Mon, Mar 6, 2017 at 5:12 PM, Nicholas Nethercote wrote: > Now for the reason I raised this: the major downside of using multiple > processes is that it increases memory usage. Recent-ish measurements showed > that for e10s-multi we could probably go up to 4 content

Re: Sheriff Highlights and Summary in February 2017

Hi Tomcat, Do you have any more details about the reasons why the 297 changesets needed to be backed out? Thanks, Lawrence On Wed, Mar 1, 2017 at 6:05 AM, Carsten Book wrote: > Hi, > > We will be more active in 2017 and inform more about whats happening in > Sheriffing and

Re: All the processes

Thank you for all the responses. Here's an updated list: - main process - content process(es): 1 on release for most users; 2 on Nightly - plugin process(es): just for Flash now? (Win32 involves two processes for Flash) - GPU process (bug 1264543, in Fx53) - Gecko Media Plugin process: one

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

Eric Rahm wrote on 06/03/2017 22:17: > I'm unaware of a bug for this decision, but https://archive.mozilla.org > stopped adding tinderbox builds back on January 18th. I haven't heard about that myself. So I'm curious if that is a regression by a change in Releng automation? I would suggest you

Re: Intent to ship: WebVR on Windows in Release

On Monday, March 6, 2017 at 12:15:25 PM UTC-8, Boris Zbarsky wrote: > On 3/6/17 3:03 PM, kearw...@kearwood.com wrote: > > The underlying VR API's expect this process to persist for the browser's > > lifespan and to have mutually-exclusive access to input from the headsets. > > It seems that the

Re: Intent to ship: WebVR on Windows in Release

On 3/6/17 3:03 PM, kearw...@kearwood.com wrote: The underlying VR API's expect this process to persist for the browser's lifespan and to have mutually-exclusive access to input from the headsets. It seems that the GPU process is the best fit afaict. In case it matters, the GPU process does

Re: Intent to ship: WebVR on Windows in Release

On Friday, March 3, 2017 at 10:42:43 AM UTC-8, Ehsan Akhgari wrote: > On Fri, Mar 3, 2017 at 12:36 PM, wrote: > > > Hi Ehsan! > > > > I believe all IPC messages can be changed to async except GetSensorState > > and SubmitFrame. We cache the results from GetSensorState and

Re: Telemetry Histogram Expiry

Bug 1334617 is taking care of FX_URLBAR_SELECTED_RESULT_INDEX FX_SANITIZE_LOADED_FLASH and FX_SANITIZE_UNLOADED_FLASH can likely be removed, also considering the future of Flash support. I'll file a bug for that. ___ dev-platform mailing list

Re: All the processes

It would be great to see this info on MDN or the public wiki :+1: On Mon, Mar 6, 2017 at 6:00 AM, wrote: > > > > -Original Message- > > From: dev-platform [mailto:dev-platform- > > bounces+jmathies=mozilla@lists.mozilla.org] On Behalf Of Nicholas > > Nethercote

[Firefox Desktop] Issues found: February 27th to March 3rd

Hi everyone, Here's the list of new issues found and filed by the Desktop Release QA Team last week, *February 27 - March 3* (week 9). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

RE: All the processes

> -Original Message- > From: dev-platform [mailto:dev-platform- > bounces+jmathies=mozilla@lists.mozilla.org] On Behalf Of Nicholas > Nethercote > Sent: Friday, March 03, 2017 6:15 PM > To: dev-platform > Subject: All the processes > > Hi, > > I

Re: All the processes

We plan to introduce JSPlugin processes, one for PDFium and one for Pepper Flash. The JSPlugin process is a kind of content process, which loads a remote iframe as a projection of or tag. It will then ask main process to spawn a plugin binary process to run PDF (or Flash) binary. Both JSPlugin