Re: Booting to the Web

[Ben Kelly]

On 11/12/2013 10:27 AM, Gabriele Svelto wrote:

Being one of the persons who wrote this code I should really be doing a
write-up of this in our Firefox OS architecture page but I didn't have
enough time for it yet :-|


I was actually thinking while reading your mail that it was a great 
write up and should be on the page.  :-)


I took the liberty of adding it here:

  https://wiki.mozilla.org/B2G/Architecture#Threading

Hope you don't mind.

Thanks!

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

Re: PSA: Don't write out multiple Add/RemoveObserver calls manually, iterate over an array instead

[Ben Kelly]

On 2/17/2014 2:25 PM, Kyle Huey wrote:

If you are observing several topics it's easy to forget to add a
Remove call when adding new observer topic.  If you instead write an
array of topics and iterate over that it's impossible to screw up
(e.g. https://hg.mozilla.org/mozilla-central/rev/3a8fe7c942e3).  We've
seen a couple of leaks caused by forgetting to remove all observers
(e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=968536#c0).


Would it be worth adding an AddObservers()/RemoveObservers() API that 
takes an array directly?  That might encourage this pattern.


Just a thought.

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

Re: We live in a memory-constrained world

[Ben Kelly]

On 2/21/2014 5:40 PM, Brian Smith wrote:

On Fri, Feb 21, 2014 at 1:38 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:

Optimizations that wouldn't have been worthwhile in the desktop-only
days are now worthwhile. For example, an optimization that saves 100
KiB of memory per process is pretty worthwhile for Firefox OS.


Do you mean 100KiB per child process? How worthwhile is it to cut
100KiB from the parent process? I ask because we have various caches
that we use for TLS security (TLS session cache, HSTS, OCSP response
cache), and I'd like to know how much memory we can can budge for
these features, given that they all affect only a single process (the
parent). In some cases, we can throw the information away and
re-retrieve and/or recompute it, but only at a cost of reduced
security and/or significantly reduced performance. In some cases, we
could try to leave the data on disk and avoid loading it into memory,
but then we run into main-thread-I/O and/or socket-thread-disk-I/O,
both of which are important to avoid for responsiveness/perf reasons.

Also, I am concerned that, AFAICT, no TLS-related testing is being
done for AWSY. Thus, a lot of my work isn't being measured there. Who
is the best person to talk to about getting TLS functionality added to
AWSY?


Not sure if these are what you are referring to, but I see nss security 
PORT_Alloc_Util() pretty consistently in parent process DMD.


In a recent DMD report I saw it accounting for ~1.2MB over a number of 
different invocations.


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

Re: Policing dead/zombie code in m-c

[Ben Kelly]

On 4/24/2014 9:20 AM, Benoit Jacob wrote:

2014-04-24 8:31 GMT-04:00 Henri Sivonen hsivo...@hsivonen.fi:

I have prepared a queue of patches that removes Netscape-era (circa
1999) internationalization code that efforts to implement the Encoding
Standard have shown unnecessary to have in Firefox. This makes libxul
on ARMv7 smaller by 181 KB, so that's a win.


Have we measured the impact of this change on actual memory usage (as
opposed to virtual address space size) ?


We are also limited by disk space in the system partition on devices 
like tarako.  So reducing lib size has a benefit even if the code is 
usually paged out.


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

Re: Intent to implement and ship: navigator.hardwareConcurrency

[Ben Kelly]

On May 15, 2014, at 1:26 AM, Rik Cabanier caban...@gmail.com wrote:
 On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari 
 ehsan.akhg...@gmail.comwrote:
...
 
 Make it possible for authors to make a semi-informed decision on how to
 divide the work among workers.
 
 
 That can already be done using the timing attacks at the waste of some CPU
 time.
 
 
 It's imprecise and wasteful. A simple attribute check is all this should
 take.

If we want to support games on mobile platforms like Firefox OS, then this 
seems like a pretty important point.

Do we really want apps on buri (or tarako) wasting CPU, memory, and power to 
determine that they should not spin up web workers?

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

Re: Intent to implement: CSSOM-View scroll-behavior property

[Ben Kelly]

On 5/23/2014 6:12 AM, Jonas Sicking wrote:

That isn't possible with APZ since the user might be actively
scrolling and so if we just do something like

div.scrollTop += hightOfNewContent;

then the newly set scroll position will be based off of an old value
which has already changed on the compositing thread.

Basically we need an API like

div.addToScrollPosition(hightOfNewContent);

This would allow the browser to send this delta to the compositing
thread along with the newly updated painting of the DOM.


Would this allow us to avoid the sync reflow currently required with the 
scrollTop approach as well?  It would seem the platform would not need 
to calculate an exact position in order to apply a delta like this.


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

proposal: cloneable input streams

[Ben Kelly]

Hello all,

I'd like to propose an addition to our nsIInputStream infrastructure.  Please 
let me know what you think.

Basics:

I propose adding this interface:

  interface nsICloneableInputStream : nsIInputStream
  {
nsIInputStream clone();
  };

The clone() method returns a copy of the stream in the most efficient manner 
possible.  This might mean different operations depending on the concrete 
implementation of the stream.

For example,

 * nsFileInputStream would simply dup() its file descriptors like when 
serializing across IPC.
 * nsStringStream would simply do an nsCString-style copy construction.
 * nsPipe would create a new nsPipeInputStream that reads from the same 
underlying pipe buffer.  The buffer is maintained until all cloned input 
streams are closed.

Motivation:

In order to implement Fetch we need to be able to clone Request and Response 
body streams. [1]  These body streams can be provided a number of ways 
resulting in different nsIInputStream implementations being used.  (Essentially 
the list above.)

Currently it seems the only infrastructure we have for performing a clone-type 
operation is to use nsIInputStreamTee.  Unfortunately this almost always does 
the sub-optimal thing in terms of memory/CPU performance by copying the entire 
stream into a new buffer.  Also, it requires that one side of the stream be 
fully read in order for the other side to have access to all the data.  If you 
have a slow reader on the primary stream then you may delay a fast reader on 
the other side.

If instead we allow the underlying stream implementations decide how to produce 
a copy then we can avoid these problems.  This is important for Fetch and 
ServiceWorkers in order to support potentially huge Response bodies in an 
efficient way.

Thoughts? Is there an existing way to accomplish this without the problems of 
nsIInputStreamTee?

Thank you!

Ben
[1] https://fetch.spec.whatwg.org/#dom-response-clone
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Default storage

[Ben Kelly]

For new quota clients like SW Cache, what storage should we now use?  Default?  
I was previously using persistent.

Thanks!

Ben

- Original Message -
From: Jan Varga jan.va...@gmail.com
To: dev-platform@lists.mozilla.org
Sent: Friday, November 28, 2014 6:04:51 PM
Subject: Default storage

Hi,

Just a heads up that default storage has landed on m-c, bug 1083927.
I'm posting to this list because there are some changes in the way how 
quota manager clients store data (mostly IndexedDB).

Old structure:
profile
   storage
 persistent
 temporary

New structure:
profile
   storage
 permanent
 temporary
 default

Some scripts (especially for B2G) put stuff into profiles directly, so 
they have to be adjusted a bit.
I expect that in most cases it should be enough to change:

profile/storage/persistent
to:
profile/storage/permanent

or

profile/storage/persistent/chrome
to:
profile/storage/permanent/chrome

For more details see the bug and sorry for any inconvenience.

Jan

___
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: Proposal: Change the coding style guide to allow an 'o' prefix to indicate out-params

[Ben Kelly]

I typically append Out to these parameter names.  The o prefix would be more 
concise.  +1

Thanks!

Ben

- Original Message -
From: Seth Fowler s...@mozilla.com
To: dev-platform dev-platform@lists.mozilla.org
Sent: Thursday, December 4, 2014 1:35:06 PM
Subject: Proposal: Change the coding style guide to allow an 'o' prefix to  
indicate out-params

I’d like to change the coding style guide to let us make out-params more 
obvious by using an ‘o’ prefix for their name instead of an ‘a’. For example,

nsresult Modify(int aCount, size_t aSize, char* oResult);

This will make it clear just from the declaration of a function or method which 
parameters are out-params. XPCOM requires us to use out-params a lot, and I’ve 
found that determining when it’s happening often requires me to look at the 
code for the method, especially since we frequently use pointer arguments for 
efficiency or because the argument is optional.

Seems to me like a substantial gain in readability for little or no cost.

- Seth
___
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 Ship: Fetch API

[Ben Kelly]

 On Feb 21, 2015, at 7:44 PM, nsm.nik...@gmail.com wrote:
 Ben, are you ok with the clone() that just landed being enabled? If so, I'll 
 flip the pref.

Clone should be good to go.  Thanks!

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

Re: Fingerprinting of battery status?

[Ben Kelly]

Can we just reduce the accuracy of the API?  Only give battery level at
certain broad breakpoints?

On Tue, Aug 4, 2015 at 11:02 AM, Chris Hofmann chofm...@mozilla.com wrote:

 I've seen a lot of GPS related tracking apps that use a lot of power
 putting up warnings to users
 that it might be time to go to low power mode and shut down the GPS if
 you'll need it
 later for navigating a critical pathway later in your journey.

 -chofmann

 On Mon, Aug 3, 2015 at 7:49 PM, Katelyn Gadd k...@luminance.org wrote:

  Games for mobile phones, handheld devices, and laptops often show a
  battery indicator and/or a clock in the corner of the screen while
  running in fullscreen mode. That's the only good reason I can think of
  off-hand.
 
  On 3 August 2015 at 12:55, Chris Peterson cpeter...@mozilla.com wrote:
   What is a legitimate use case for a web page to know my battery status?
   Battery level and time remaining can be used to fingerprint users.
  
   A mobile webapp might use battery level to throttle its activity, but
  that
   could be something the OS handles by pausing or throttling apps
 directly
  or
   broadcasting app lifecycle events. I can't think of a good reason why a
  web
   page in a browser, especially on a desktop OS, needs to know anything
  about
   my battery.
  
  
 
 http://www.theguardian.com/technology/2015/aug/03/privacy-smartphones-battery-life
  
   http://eprint.iacr.org/2015/616.pdf
  
  
   chris
   ___
   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
 
 ___
 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 unship: Request.context

[Ben Kelly]

On Mon, Jul 27, 2015 at 5:55 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:

 This was shipped in Firefox 39, but this attribute is fairly useless
 without service workers since it can only be read from Request objects and
 its value will always be fetch for manually created Request objects.


Actually, it sounds like we're not quite right there either.  It should now
be  for synthetically created Request objects.  The fetch() method copies
to a new Request object with fetch context.  Thats not observable without
the fetch event, though.

Anyway, that's beside the point right now if we are disabling it.

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

Re: Intent to unship: jar: URIs from content

[Ben Kelly]

On Oct 16, 2015 6:17 PM, "Robert O'Callahan"  wrote:
> I guess the right fix would be to have a Web proxy service that accepts
> URLs in a custom format, unpacks ZIP files and serves their contents.

Bugzilla could do this in a service worker.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: revisit and implement navigator.hardwareConcurrency

[Ben Kelly]

FWIW, I also think we should implement this.  The clamping seems like a
reasonable way to be conservative given the fingerprinting concerns.

On Tue, Sep 8, 2015 at 3:21 PM, Luke Wagner  wrote:

> Since the original m.d.p thread on hardwareConcurrency last year:
>
> https://groups.google.com/d/topic/mozilla.dev.platform/QnhfUVw9jCI/discussion
> the landscape has shifted (as always) and I think we should reevaluate
> and implement this feature.
>
> What hasn't changed are the arguments, made in the original thread,
> that hardwareConcurrency is a clumsy way to decide how many workers to
> create and can lead to the creation of too many workers in various
> scenarios (e.g., multiple tabs all attempting to saturate all the cores,
> cores vs. hyperthreads).
>
> What has changed is the appearance of more compelling use cases.  In
> particular, the upcoming support for SharedArrayBuffer [1][2] allows
> Emscripten to compile pthreads [3] applications, which has been the #1
> compile-to-web feature request over the last few years. Specifically,
> native
> game engines find the number of logical cores on the machine (using APIs
> present in C++11, etc.), and use a number of threads based on that (often
> adjusted, and they have a lot of experience tuning this). They would like
> to
> do the same on the web, and Chrome and Safari already let them. In the
> absence of hardwareConcurrency, developers are forced to resort to either
> hardcoding a constant number of workers or using a polyfill library [4]
> that
> estimates the number of cores. Unfortunately, the polyfill takes a few
> seconds (hurting startup time) and produces inaccurate results (based on
> evaluations from multiple parties) [5]. Thus, while hardwareConcurrency
> isn't ideal, it's strictly better than what developers have now in Firefox.
>
> Moreover, I don't think the applicability of hardwareConcurrency is
> limited to compile-to-web uses.  I think all the use cases we're
> seeing now from compiled native apps will manifest in JS apps further
> down the line as worker usage becomes more commonplace and
> applications grow more demanding.  As in many other cases, I think
> games are serving as a catalyst here, proving what's possible and
> paving the way for fleets of non-game applications.
>
> But will the existence of hardwareConcurrency encourage bad behavior
> in every-day web browsing?  I don't think so.  First of all,
> hardwareConcurrency is meant to help good actors who want to
> ensure a good experience for their users.  Bad actors can already
> saturate all your cores with Workers. Thus, as Worker (mis)use
> becomes more widespread on the Web, it seems inevitable we'll need
> to do some form of Worker throttling (via thread priority or
> SuspendThread/pthread_kill) of background/invisible windows *anyway*;
> it seems like the only reason we haven't had to do this already is
> because Workers just aren't used that much in normal web apps.  For
> good actors, though, it is possible to mitigate some of the clumsiness
> of hardwareConcurrency: using SharedWorkers to detect the "same
> app open in many tabs" case; using the PageVisibility API to pause
> work when not visible (which will likely happen anyway in frame-driven
> applications based on requestAnimationFrame throttling of background
> tabs).  Lastly, for neither good nor bad actors, I think the hazard of
> casual/widespread use is more limited by the hurdles of using workers
> at all (w/ or w/o SharedArrayBuffer).
>
> Will we get stuck with hardwareConcurrency forever?  I don't think
> so.  Farther down the line, as more web apps take advantage of workers
> and we find real examples of CPU contention for which throttling
> mitigations aren't sufficient, we will be motivated to improve and
> propose a more responsive API.  However, I don't think we can design
> that API now: we don't have the use cases to evaluate the API against.
> This is the basic Web evolutionary strategy.
>
> On the subject of fingerprinting: as stated above, core count can
> already be roughly measured [4].  While the extra precision and speed
> of hardwareConcurrency does make fingerprinting somewhat easier, as
> we've done with other features, we need to weigh the value to users
> against information revealed.  In this case, it seems like the ratio
> is pretty heavily weighted toward the value.
>
> On a more technical detail: WebKit and Chromium have both shipped,
> returning the number of logical processors where WebKit additionally
> clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed
> by WHATWG text [7].  I would argue for not clamping (like Chrome),
> although I do think we'll have a good amount of flexibility to change
> clamping over time based on experience.
>
> How does that sound?
>
> Cheers,
> Luke
>
> [1]
> https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/
> [2] https://github.com/lars-t-hansen/ecmascript_sharedmem
> [3]
> 

service worker fetch interception riding to aurora 43

[Ben Kelly]

Hello all,

Currently service workers are enabled in 42 to support push notifications,
but network interception via the FetchEvent is disabled.  We've made a lot
of progress on the issues blocking this interception, however, and we feel
we are ready to move forward.

Therefore, we intend to let service worker fetch interception ride the
trains to aurora in 43 for desktop.  We think android could also ride the
trains, but need to verify how that team feels about it.  Service workers
will definitely not ship on b2g as there are a number of issues there
currently.

We also intend to continue improving service workers on aurora 43 where we
can make targeted uplifts.  We expect these changes to be mostly
improvements to test coverage and isolated fixes uncovered by those tests.

Before 43 merges to beta we will re-evaluate where we stand and decide if
service worker fetch interception should ride the trains to release.  If we
decide to proceed, we will send an intent-to-ship at that time.

Of course, if we encounter any major new problems that cannot be fixed in
an uplift, then we will not ship to release in 43.  We may also disable
service workers on aurora depending on the nature of the issue.

Here are the list of bugs we consider blocking release of the feature:


https://bugzilla.mozilla.org/showdependencytree.cgi?id=1059784_resolved=1

Note that we expect to land many of these prior to the merge on Monday.

Please let us know if there are questions or concerns.

Thank you.

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

Re: Intent to disable service workers in 45 ESR

[Ben Kelly]

Just to clarify, since some people asked:

Firefox 44 = SW enabled
Firefox 45 = SW enabled
Firefox 45 ESR = SW disabled

Only the ESR channel will be disabled.  Normal 45 installs will have the 
feature enabled.

Sorry for any confusion.

Ben

> On Dec 11, 2015, at 2:47 PM, Ben Kelly <bke...@mozilla.com> wrote:
> 
> Hello,
> 
> We are currently planning to ship service workers in firefox 44 on both 
> desktop and android.  AFAIK, the next ESR is going to be firefox 45.  We plan 
> to disable service workers on all platforms for the ESR release.
> 
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1232029
> 
> We're doing this for a couple reasons:
> 
> 1) Our implementation is likely to change in significant ways in the next few 
> months that will make it quite hard to perform uplifts.
> 2) The spec is still changing; sometimes in significant ways.
> 
> We feel freezing the current service worker API in an ESR will create too 
> many compat issues over the next 9 months or so.  Therefore we plan to enable 
> the feature only in our evergreen release branches.
> 
> Please let us know if there are any concerns.
> 
> Thank you.
> 
> Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to disable service workers in 45 ESR

[Ben Kelly]

Hello,

We are currently planning to ship service workers in firefox 44 on both
desktop and android.  AFAIK, the next ESR is going to be firefox 45.  We
plan to disable service workers on all platforms for the ESR release.

  https://bugzilla.mozilla.org/show_bug.cgi?id=1232029

We're doing this for a couple reasons:

1) Our implementation is likely to change in significant ways in the next
few months that will make it quite hard to perform uplifts.
2) The spec is still changing; sometimes in significant ways.

We feel freezing the current service worker API in an ESR will create too
many compat issues over the next 9 months or so.  Therefore we plan to
enable the feature only in our evergreen release branches.

Please let us know if there are any concerns.

Thank you.

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

Re: Too many oranges!

[Ben Kelly]

On Tue, Dec 22, 2015 at 7:29 PM, Douglas Turner <do...@mozilla.com> wrote:

> Thanks Ben -- really great.  Let me know you need anything or if things
> get stuck!
>

No problem.  Although I should note David Baron has already NI'd a bunch of
people on the top orange bugs.

Thanks.

Ben


>
> Doug
>
> On Tue, Dec 22, 2015 at 4:00 PM Ben Kelly <bke...@mozilla.com> wrote:
>
>> I'll triage the top orange tomorrow and try to find some owners for
>> things.
>>
>> After the new year I'll set something weekly up to stay on top of things.
>> On Dec 22, 2015 2:58 PM, "Jason Duell" <jdu...@mozilla.com> wrote:
>>
>>>
>>>
>>> On Tue, Dec 22, 2015 at 11:38 AM, Ben Kelly <bke...@mozilla.com> wrote:
>>>
>>>>
>>>> I'd rather see us do:
>>>>
>>>> 1) Raise the visibility of oranges.  Post the most frequent
>>>> intermittents
>>>> without an owner to dev-platform every N days.
>>>> 2) Make its someone's job to find owners for top oranges.  I believe
>>>> RyanVM
>>>> used to do that, but not sure if its still happening now that he has
>>>> changed roles.
>>>>
>>>> Ben
>>>>
>>>>
>>> I'm with bkelly on this one.  Maybe with some additional initial
>>> messaging ("War on Orange raised in priority!") too.  I don't think we want
>>> to pivot all work in platform for this.
>>>
>>> Jason
>>>
>>>
>>>
>>>>
>>>> >
>>>> > On Tue, Dec 22, 2015 at 7:41 AM Mike Conley <mcon...@mozilla.com>
>>>> wrote:
>>>> >
>>>> > > I would support scheduled time[1] to do maintenance[2] and help
>>>> improve
>>>> > our
>>>> > > developer tooling and documentation. I'm less sure how to integrate
>>>> such
>>>> > a
>>>> > > thing in practice.
>>>> > >
>>>> > > [1]: A day, a week, heck maybe even a release cycle
>>>> > > [2]: Where maintenance is fixing oranges, closing out papercuts,
>>>> > > refactoring, etc.
>>>> > >
>>>> > > On 21 December 2015 at 17:35, <jmath...@mozilla.com> wrote:
>>>> > >
>>>> > > > On Monday, December 21, 2015 at 1:16:13 PM UTC-6, Kartikaya Gupta
>>>> > wrote:
>>>> > > > > So, I propose that we create an orangefactor threshold above
>>>> which
>>>> > the
>>>> > > > > tree should just be closed until people start fixing
>>>> intermittent
>>>> > > > > oranges. Thoughts?
>>>> > > > >
>>>> > > > > kats
>>>> > > >
>>>> > > > How about regularly scheduled test fix days where everyone drops
>>>> what
>>>> > > they
>>>> > > > are doing and spends a day fixing tests? mc could be closed to
>>>> > everything
>>>> > > > except critical work and test fixes. Managers would be able to opt
>>>> > > > individuals out of this as needed but generally everyone would be
>>>> > > expected
>>>> > > > to take part.
>>>> > > >
>>>> > > > Jim
>>>> > > > ___
>>>> > > > 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
>>>> > >
>>>> > ___
>>>> > 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
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Jason
>>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

unowned orange by team

[Ben Kelly]

Hi all,

In an attempt to wrangle some of the orange plaguing the tree I've tried to
triage the top unowned bugs by team.

If you are working one of these bugs, please assign yourself to it.  If
you're not working a bug, but are assigned, please drop it so we can see
the status.

If you see bugs in your team, please feel free to jump on it.  I'm also
going to try to track down a manager for each team to see if they can help
prioritize things.  Of course, the holiday will complicate things, but
maybe we can get this sorted quickly when we get back from break.

Thanks everyone!

Of the top 30 orange we have only six that are clearly being owned and
worked by someone.  The rest fall into these rough categories/teams:

memory:
1) https://bugzilla.mozilla.org/show_bug.cgi?id=1220517
20) https://bugzilla.mozilla.org/show_bug.cgi?id=1218297

addons:
4) https://bugzilla.mozilla.org/show_bug.cgi?id=1135866

ateam/releng:
5) https://bugzilla.mozilla.org/show_bug.cgi?id=1197950
9) https://bugzilla.mozilla.org/show_bug.cgi?id=1198092
10) https://bugzilla.mozilla.org/show_bug.cgi?id=1231798
17) https://bugzilla.mozilla.org/show_bug.cgi?id=1073442
18) https://bugzilla.mozilla.org/show_bug.cgi?id=1204281
25) https://bugzilla.mozilla.org/show_bug.cgi?id=1231034
30) https://bugzilla.mozilla.org/show_bug.cgi?id=1234416

necko:
7) https://bugzilla.mozilla.org/show_bug.cgi?id=1203430
12) https://bugzilla.mozilla.org/show_bug.cgi?id=1233774

firefox:
8) https://bugzilla.mozilla.org/show_bug.cgi?id=1182072
9) https://bugzilla.mozilla.org/show_bug.cgi?id=1230027

e10s:
11) https://bugzilla.mozilla.org/show_bug.cgi?id=1230978

dom:
14) https://bugzilla.mozilla.org/show_bug.cgi?id=1197786
15) https://bugzilla.mozilla.org/show_bug.cgi?id=1227320
24) https://bugzilla.mozilla.org/show_bug.cgi?id=1203441
27) https://bugzilla.mozilla.org/show_bug.cgi?id=1213633

layout:
19) https://bugzilla.mozilla.org/show_bug.cgi?id=1204897

devtools:
21) https://bugzilla.mozilla.org/show_bug.cgi?id=992275
22) https://bugzilla.mozilla.org/show_bug.cgi?id=1210208
23) https://bugzilla.mozilla.org/show_bug.cgi?id=1230031
29) https://bugzilla.mozilla.org/show_bug.cgi?id=1209295

android:
23) https://bugzilla.mozilla.org/show_bug.cgi?id=1213030
28) https://bugzilla.mozilla.org/show_bug.cgi?id=1118268

fxos:
24) https://bugzilla.mozilla.org/show_bug.cgi?id=999675

Thanks again for your help with this.

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

Re: unowned orange by team

[Ben Kelly]

Thanks for everyone's help!

I did just want to clarify, though, that I don't think anyone should be
changing holiday plans to work these bugs.  We can address them as people
come back from PTO.  Everyone having a good break and holiday is more
important.

Sorry for any confusion and thanks again.  Happy holidays everyone!

Ben

On Tue, Dec 22, 2015 at 8:15 PM, Ben Kelly <bke...@mozilla.com> wrote:

> Hi all,
>
> In an attempt to wrangle some of the orange plaguing the tree I've tried
> to triage the top unowned bugs by team.
>
> If you are working one of these bugs, please assign yourself to it.  If
> you're not working a bug, but are assigned, please drop it so we can see
> the status.
>
> If you see bugs in your team, please feel free to jump on it.  I'm also
> going to try to track down a manager for each team to see if they can help
> prioritize things.  Of course, the holiday will complicate things, but
> maybe we can get this sorted quickly when we get back from break.
>
> Thanks everyone!
>
> Of the top 30 orange we have only six that are clearly being owned and
> worked by someone.  The rest fall into these rough categories/teams:
>
> memory:
> 1) https://bugzilla.mozilla.org/show_bug.cgi?id=1220517
> 20) https://bugzilla.mozilla.org/show_bug.cgi?id=1218297
>
> addons:
> 4) https://bugzilla.mozilla.org/show_bug.cgi?id=1135866
>
> ateam/releng:
> 5) https://bugzilla.mozilla.org/show_bug.cgi?id=1197950
> 9) https://bugzilla.mozilla.org/show_bug.cgi?id=1198092
> 10) https://bugzilla.mozilla.org/show_bug.cgi?id=1231798
> 17) https://bugzilla.mozilla.org/show_bug.cgi?id=1073442
> 18) https://bugzilla.mozilla.org/show_bug.cgi?id=1204281
> 25) https://bugzilla.mozilla.org/show_bug.cgi?id=1231034
> 30) https://bugzilla.mozilla.org/show_bug.cgi?id=1234416
>
> necko:
> 7) https://bugzilla.mozilla.org/show_bug.cgi?id=1203430
> 12) https://bugzilla.mozilla.org/show_bug.cgi?id=1233774
>
> firefox:
> 8) https://bugzilla.mozilla.org/show_bug.cgi?id=1182072
> 9) https://bugzilla.mozilla.org/show_bug.cgi?id=1230027
>
> e10s:
> 11) https://bugzilla.mozilla.org/show_bug.cgi?id=1230978
>
> dom:
> 14) https://bugzilla.mozilla.org/show_bug.cgi?id=1197786
> 15) https://bugzilla.mozilla.org/show_bug.cgi?id=1227320
> 24) https://bugzilla.mozilla.org/show_bug.cgi?id=1203441
> 27) https://bugzilla.mozilla.org/show_bug.cgi?id=1213633
>
> layout:
> 19) https://bugzilla.mozilla.org/show_bug.cgi?id=1204897
>
> devtools:
> 21) https://bugzilla.mozilla.org/show_bug.cgi?id=992275
> 22) https://bugzilla.mozilla.org/show_bug.cgi?id=1210208
> 23) https://bugzilla.mozilla.org/show_bug.cgi?id=1230031
> 29) https://bugzilla.mozilla.org/show_bug.cgi?id=1209295
>
> android:
> 23) https://bugzilla.mozilla.org/show_bug.cgi?id=1213030
> 28) https://bugzilla.mozilla.org/show_bug.cgi?id=1118268
>
> fxos:
> 24) https://bugzilla.mozilla.org/show_bug.cgi?id=999675
>
> Thanks again for your help with this.
>
> Ben
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: about:profiles and the new profile manager

[Ben Kelly]

I really like being able to manage my profiles within a normal firefox
tab.  Awesome!

The replacement for the ProfileManager probably needs some UX work,
though.  It was not clear to me which profile was actually going to be
launched if I clicked the "Start Nightly" button.

On Fri, Dec 18, 2015 at 12:17 PM, Andrea Marchesini  wrote:

> Hi all,
>
> This week I landed a set of patches to introduce 'about:profiles'.
> This page shows the list of existing profiles and gives the possibility to
> create new ones, delete them, rename them, change the default one.
>
> I wanted to work on this feature because I think having multiple profiles
> and manage them with a simple UI is extremely useful and it's important for
> web developers who want to test a websites with different logins, people
> who care about privacy and want to have different profiles for different
> use-case, and so on.
>
> This page/feature is not meant to be a replacement of containers:
> containers have a completely different workflow, it's a major feature of
> firefox and I want to see it enabled by default on nightly :)
>
> I also landed a replacement of the existing ProfileManager, built on top of
> about:profiles: instead having a XUL UI, we show a XUL browser element
> rendering |about:profiles?manage|. This new profile manager offers the same
> features of the previous one.
>
> There are still a couple of open issues, and maybe more will come. But I'm
> working on them and I'm having good feedback.
>
> b
> ___
> 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: Too many oranges!

[Ben Kelly]

Does anyone feel the changes to how intermittents are reported to bugs has
affected things?  We used to get a comment for each intermittent, but now
its rolled up into a periodic summary.  Perhaps people feel less urgency to
fix things without the constant bugmail.  Not that I want to advocate
spam...  but it is a recent change.

On Tue, Dec 22, 2015 at 10:40 AM, Mike Conley  wrote:

> I would support scheduled time[1] to do maintenance[2] and help improve our
> developer tooling and documentation. I'm less sure how to integrate such a
> thing in practice.
>
> [1]: A day, a week, heck maybe even a release cycle
> [2]: Where maintenance is fixing oranges, closing out papercuts,
> refactoring, etc.
>
> On 21 December 2015 at 17:35,  wrote:
>
> > On Monday, December 21, 2015 at 1:16:13 PM UTC-6, Kartikaya Gupta wrote:
> > > So, I propose that we create an orangefactor threshold above which the
> > > tree should just be closed until people start fixing intermittent
> > > oranges. Thoughts?
> > >
> > > kats
> >
> > How about regularly scheduled test fix days where everyone drops what
> they
> > are doing and spends a day fixing tests? mc could be closed to everything
> > except critical work and test fixes. Managers would be able to opt
> > individuals out of this as needed but generally everyone would be
> expected
> > to take part.
> >
> > Jim
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Service Workers with FetchEvent

[Ben Kelly]

In Firefox 44 we intend to enable Service Workers and FetchEvents by
default on desktop and android.  These features will not be enabled on
Firefox OS yet.

They has been developed behind the following preferences:

  dom.serviceWorkers.enabled
  dom.serviceWorkers.interception.enabled
  dom.serviceWorkers.interception.opaque.enabled

Chrome has been shipping Service Workers with FetchEvent since Chrome 40.

Unfortunately, I can't find a previous intent to implement for service
workers.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1226686
Standard:
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html

Please let me know if you have any questions are concerns.

Thanks.

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

Re: Intent to ship: Service Workers with FetchEvent

[Ben Kelly]

On Fri, Nov 20, 2015 at 3:30 PM, Boris Zbarsky  wrote:

>
> Another compat issue we need to fix is returning the same
>> ServiceWorkerRegistration object repeatedly from certain APIs.  This was
>> something that changed a few times in both the spec and chrome.
>>
>> Fixing these minor compat issues is on our todo list for the rest of the
>> 45
>> cycle leading up to orlando.
>>
>
> OK.  Are there plans to uplift any of this to 44?
>

No.  I think what we have works on the sites/demos/wpt tests available
today.  We feel its compatible enough to ship.  We'll fix further compat
issues using our standard train model.


> Overall I expect to get reports of compat issues.
>>
>
> That's fair.  Again, the main question I have is whether giving our impl
> and the spec more bake time would help with this or just push it off while
> leaving the scope of the problem about the same.  It sounds like you don't
> think it would really help, right?


I think the best thing we can do right now is get a second implementation
into wide circulation.  This will highlight compat issues yes, but also
help avoid baking chrome specific behavior into all the sites using service
workers.

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

Re: Intent to ship: Service Workers with FetchEvent

[Ben Kelly]

On Fri, Nov 20, 2015 at 3:21 PM, Ben Kelly <bke...@mozilla.com> wrote:

>
> On Fri, Nov 20, 2015 at 3:01 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
>
>>
>> 1)  How confident are we that the spec is stable/correct?
>>
>
> The spec is converging to a stable v1, but things are still changing.  The
> core functionality has been stable for a while, though.
>

I guess I should mention the biggest change in the spec that has not been
implemented by either chrome or firefox.

The spec now exposes the Response.url passed to the
FetchEvent.respondWith() to the outer network request.  So base URLs for
stylesheets and workers will have a different URL.  A window doing fetch()
will see a different Response.url.

This was changed so that relative path subresources in stylesheets and
workers will continue to work.

I've mentioned to google it would be helpful to do a coordinated release
for this particular spec change.  Here is the chrome issue:

  https://code.google.com/p/chromium/issues/detail?id=553535

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

Re: Intent to ship: Service Workers with FetchEvent

[Ben Kelly]

On Fri, Nov 20, 2015 at 3:01 PM, Boris Zbarsky  wrote:

>
> 1)  How confident are we that the spec is stable/correct?
>

The spec is converging to a stable v1, but things are still changing.  The
core functionality has been stable for a while, though.


> 2)  How confident are we that our implementation, Chrome's, and the spec
> all match?  I know we were working on importing some of their tests, so I'm
> guessing fairly confident, but just wanted to check.
>

We imported blink's web-platform-tests.  We found some spec issues with
them and tried to flow them all back to both spec and google.

There are some corner cases where we differ or might differ depending on
release schedules.  For example, the spec now says that navigations should
set a RequestMode of "navigate", but neither chrome or firefox do this.  We
set "same-origin" as the spec used to say.  I believe chrome has patches in
flight to change, but we have not started yet.

Another compat issue we need to fix is returning the same
ServiceWorkerRegistration object repeatedly from certain APIs.  This was
something that changed a few times in both the spec and chrome.

Fixing these minor compat issues is on our todo list for the rest of the 45
cycle leading up to orlando.

Also, we have implemented more of the spec in some areas than chrome.  For
example, I believe chrome's Cache API is still not complete on their
release channel.  We have a complete Cache API already shipped in FF39.


> 3)  Have we heard anything from Apple or Microsoft about their plans, or
> lack thereof, for Service Workers?
>

They have been attending face-to-face meetings, but no official
implementation announcements as far as I know.

The webkit project's 5 year plan includes service workers:

  http://trac.webkit.org/wiki/FiveYearPlanFall2015


> 4)  Are there significant parts of the spec we're not shipping yet?  Is
> Chrome shipping those parts?  Is support for those feature-detectable?
>

I don't think we are missing anything significant in the service worker
spec.  Other features building on top of service workers like push,
background-sync, etc are in separate specs.

Fetch body streams is something that was spec'd recently.  Chrome has it
partly implemented, but I don't think their shipping implementation is spec
compatible.

I believe all these APIs are feature detectable.

Overall I expect to get reports of compat issues.  I think thats inevitable
with such a large feature and complex feature.  We'll have to hash it out
in spec issues, write WPT tests, and ship the fix.  I'm not sure how else
to realistically move forward, though.

I hope that answers your questions.

Thanks.

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

Re: 32-bit developer edition?

[Ben Kelly]

On Mon, Jun 6, 2016 at 1:47 PM, Jared Wein  wrote:

> We shouldn't hold back on providing a link to 64-bit Dev Edition users en
> masse. I worry that running an A/B test will slow down the full release
> without telling us much of anything that we don't already know.
>
> The user agent string says if the system is 64-bit, so sniffing is already
> possible.
>
> Ben, can you file the bug in Mozilla.org::webdev to get the link added to
> the download page?
>

Sure:

https://bugzilla.mozilla.org/show_bug.cgi?id=1278315
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

32-bit developer edition?

[Ben Kelly]

Hi all,

I noticed recently that all of the available download links for dev edition
point to the 32-bit installer.  Is there a reason for this?

Given we are talking about how to upgrade existing users to 64-bit it would
seem good to update the download links for new installs.

Thanks.

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

Re: 32-bit developer edition?

[Ben Kelly]

On Jun 3, 2016 2:15 AM, "Jet Villegas"  wrote:
>
> We should offer both.

If we get a net reduction in OOMs with 64-bit it seems to me we should make
that the default download link.

In any case, we're not showing a 64-bit link anywhere now.  Who should I
pester or where should I file a bug to get that fixed?

Thanks.

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

Re: Service Worker - Offline fallback not working

[Ben Kelly]

On May 30, 2016 1:55 PM, "Mohit Bajoria"  wrote:
> Offline fallback event is not working.
> Can anyone please let me know the error and help me solving the issue ?

Can you describe what you expect and what you are actually seeing happen?

There is no "offline fallback event", so not sure exactly what you mean.

Thanks.

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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Ben Kelly]

On Tue, May 31, 2016 at 10:28 AM, Milan Sreckovic 
wrote:

> On a side note, the one that stood out for me was a “TODO” one.  A crash
> seems to be a wrong way to tag TODOs :)
>

FWIW, this appears to have been fixed last week:

https://hg.mozilla.org/mozilla-central/rev/a61e4c04aadb
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Heads Up: Cache API .add()/.addAll() non-backward compatible change

[Ben Kelly]

All,

We just landed a change to the Cache API .add()/.addAll() methods here:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1244764

These methods essentially perform a fetch() and then a cache.put().
Previously they would happily store a 40x or 50x response from the fetch()
in the Cache.  This surprised many developers.

Cache .add() and .addAll() will now reject with a TypeError if any Response
status is not in the 200 range.

An additional side effect of this is that these methods will always reject
for cross-origin no-cors requests resulting in opaque responses since these
responses hide the status code.  They always return a status of 0.  The
blink team did some measurements and confirmed this is a very rare thing
right now in the wild.  So we decided it was a reasonable breaking change
to make.

Chrome has landed the same fix and will ship it in M50 in the april'ish
time frame:


https://github.com/slightlyoff/ServiceWorker/issues/823#issuecomment-179394502

I plan to uplift this change to FF46 so that we will also ship in april.

Please let me know if you have any concerns.

Thanks!

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

Re: Testing Wanted: APZ Scrollbar dragging

[Ben Kelly]

This suggests it's possible to use a Bluetooth mouse with an Android device:

https://mobile.twitter.com/patrick_h_lauke/status/698898777562836992
On Feb 17, 2016 6:27 PM, "Benoit Girard"  wrote:

> This is mouse based. I don't believe we support mouses at all on mobile. I
> also don't think we support touch interacting with the scroll thumb on
> mobile. So unless there's an unusual device configuration I don't think
> this applies to mobile.
>
> On Wed, Feb 17, 2016 at 4:34 PM, Nicholas Alexander <
> nalexan...@mozilla.com>
> wrote:
>
> > Benoit, (possibly kats),
> >
> > On Wed, Feb 17, 2016 at 10:35 AM, Benoit Girard 
> > wrote:
> >
> >> Currently APZ does not cause scrollbar initiated scrolling to be async.
> >> I've been working in fixing this and I'd like some help testing it out
> >> before enabling it on Nightly. If you're interested please flip
> >> 'apz.drag.enabled' to true and restart. If you find any issue please
> make
> >> it block https://bugzilla.mozilla.org/show_bug.cgi?id=1211610.
> >>
> >
> > Does this apply to Fennec?  Do you also want testing on Fennec?  A
> > cross-post to mobile-firefox-dev might be in order.
> >
> > Nick
> >
> ___
> 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 implement: W3C WebAppSec credentialmanagement API

[Ben Kelly]

Thanks for taking this on Alex!

I had some initial concerns with the API from a fetch/SW perspective, but
Mike seems open to addressing them:

  https://github.com/w3c/webappsec-credential-management/issues/11

I believe Matthew Noorenberghe had some concerns about the necessity of the
API given requestAutocomplete:


https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
  https://github.com/w3c/webappsec-credential-management/issues/2

We should probably come to some consensus there before moving forward.

Thanks again.

Ben

On Thu, Mar 10, 2016 at 1:56 PM, Axel Nennker  wrote:

> Summary: This API is enabling a website to request a user's credentials
> from a user agent, and helps the user agent to correctly store user
> credentials for future use. It helps the LoginManager to get rid of most of
> the heuristics.
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1156047
> Link to standard: https://w3c.github.io/webappsec-credential-management/
> Platform coverage: Desktop first, every platform that today has
> LoginManager
> Current code is here: https://github.com/AxelNennker/firefox_credentials/
> Estimated or target release: spec is still work in progress
> Preference behind which this will be implemented: not implemented yet
> DevTools bug:
> Suggested Additions: none, minimal viable API e.g. no password generation
> help by the UA. Federated Identity support is probably removed in the next
> version.
>
> Intend to ship in Chrome:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/7ouLjWzcjb0
>
> Web designer / developer use-cases: examples are in the spec
> ___
> 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: An analysis of content process memory overhead

[Ben Kelly]

On Thu, Mar 17, 2016 at 9:50 AM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:

> Source compressions should already be enabled.  I think we do not do it
> for small sources, and for Huge sources, as the compression would either be
> useless, or it would take a noticeable amount of time.
>

I think Luke suggested that we could compress larger JS sources off the
main thread if we implemented this bug:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1001231

Its been in my queue for 2 years, unfortunately.  If anyone wants to make
that happen, please feel free to steal it. :-)

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

Re: Skia Content on OS X

[Ben Kelly]

On Tue, Mar 22, 2016 at 11:44 AM, William Lachance 
wrote:

> On 2016-03-22 11:21 AM, Mike de Boer wrote:
>
>> I was also quite curious, so I started clicking up the hierarchy of that
>> bug and ended up at:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1154825#c1 <
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1154825#c1>
>>
>> (comment 2 is also useful info)
>>
>> Ultimate goal: no more checkerboarding in APZ. But Mason is the authority
>> here, methinks :-)
>>
>
> Yeah, there were some really nice wins as a result of this change that
> Perfherder picked up:
>
> https://treeherder.mozilla.org/perf.html#/alerts?id=534
>

Have we done any measurements on how this impacts battery usage?  Just
curious.

Thanks!

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

Re: Redesigning the docshell/loadgroup/document interaction

[Ben Kelly]

On Fri, May 20, 2016 at 10:56 AM, Boris Zbarsky  wrote:

> Thoughts?  Any obvious problems with this plan?
>

We have the concept of network requests made from workers not associated
with a single document.  For example, SharedWorker attached to multiple
documents or a ServiceWorker servicing a push event.  In theory we want the
same load grouping behavior to abort requests if those workers terminate,
etc.

If we are refactoring things, can we include that concept as well?

Thanks.

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

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On Fri, May 20, 2016 at 8:10 PM, Ben Kelly <bke...@mozilla.com> wrote:

> On Fri, May 20, 2016 at 11:09 AM, Ben Kelly <bke...@mozilla.com> wrote:
>
>> On Fri, May 20, 2016 at 7:37 AM, Honza Bambas <hbam...@mozilla.com>
>> wrote:
>>
>>> And I do! :)  Actually any parent necko channel, mainly HTTP, which
>>> sends data to the child process.  We also have bug 1110596 which complains
>>> about too much memory copying in that code.
>>> Could your IPCStream be used for that?
>>>
>>
>> Yes, I think that could work in general.
>>
>> I think the main issue would be compat with existing nsIStreamListeners.
>> These listeners might be written such that they expect the nsIInputStream
>> passed in OnDataAvailable() to return their entire length from a single
>> Available() call.  This will not be true for a streamed pipe.
>>
>
> Actually, the nsIStreamListener interface explicitly requires a fixed
> length nsIInputStream:
>
> "The onDataAvailable impl must read exactly |aCount| bytes of data before
> returning."
>
> From:
>
>
> https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl#18
>
> I don't think we can use a pipe-oriented stream here without changing that
> interface contract.
>

Is there a reason we can't just make necko code call OnDataAvailable()
multiple times with a different slice of the giant buffer?  It already has
the mechanism for chunked data.  It just needs to split the single buffer
into multiple callouts.

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

IPCStream landed in mozilla-central

[Ben Kelly]

Hi all,

FYI, I've landed a new IPDL type in bug 1093357 called IPCStream.  This is
intended to make it easier to serialize nsIInputStreams across IPC.

In short, IPCStream:

1) Supports our existing serializable nsInputStreams.
2) Also automatically handles send file descriptors using the
PFileDescriptorSet actor
3) Supports async pipe streams using a new PSendStream actor from
*child-to-parent*.  I have plans to add support for parent-to-child, but I
don't have a consumer yet and we need to figure out some issues with
PBackground targeting worker threads.

Because the actors require special care there is also a new RAII type
called AutoIPCStream.

A short example of using these types:

  // ipdl
  protocol PMyStuff
  {
  parent:
async DoStuff(IPCStream aStream);
  }

  // in the child
  void
  CallDoStuff(PMyStuffChild* aActor, nsIInputStream* aStream)
  {
AutoIPCstream autoStream;
autoStream.Serialize(aStream, aActor->Manager());
aActor->SendDoStuff(autoStream.TakeValue());
  }

  // in the parent
  bool
  MyStuffParent::RecvDoStuff(const IPCStream& aIPCStream)
  {
nsCOMPtr stream = DeserializeIPCStream(aIPCStream);
// do something with the stream
  }

This example and more documentation can be found in the comments in
IPCStreamUtils.h:

https://dxr.mozilla.org/mozilla-central/source/ipc/glue/IPCStreamUtils.h#31

For the most part you should be able to replace ipdl like:

  InputStreamParams streamParams;
  FileDescriptorSet streamFds;

With:

  IPCStream stream;

Note, however, some code will assume it gets a fixed length stream from IPC
because that is all we have supported in the past.  You should audit the
code to make sure it supports variable length streams.

For example, necko expects to be able to call Available() on the stream in
the parent in order to set content-length.  In order to support the
IPCStream pipe mechanism necko needs to implement chunked uploads or
accumulate the stream before setting the content-length.

Right now the AutoIPCStream::Serialize() method will automatically try
serialization in this order:

1) Fixed length serialization
2) Variable length serialization

We could expand the API to favor one over the other or restrict to only one
kind of serialization.

There is one consumer using IPCStream at the moment; dom/cache.  Its a bit
of a complex example, though, since Cache API needs to send arrays of
streams in a single IPC call.  I tried to include adequate examples in
IPCStreamUtils.h to compensate for this.

Anyway, I hope this helps people dealing with nsInputStreams and ipdl
interfaces.  Please let me know if you run into any problems or have
questions.

Thanks.

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

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On May 21, 2016 7:45 AM, "Honza Bambas"  wrote:
> But that doesn't mean "a fixed length input stream" - actually I may not
even follow how you have translated this to you.

Sorry, I was thinking a single OnDataAvailable call for the one IPC call
just passing the stream.  Clearly that won't work, though.

> As I understand, your impl of Available() may return _different_ number
of bytes than the stream is then able to deliver when Read/ReadSegments on
it is called, right?  Can you explain why?

No.  Available() should work fine.  It's just an nsPipeInputStream.

So we should be able to loop and call ODA for each ReadSegments callback
after the IPC hop.

Sorry for my confusion.

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

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On May 21, 2016 9:44 AM, "Honza Bambas"  wrote:
> If it's nsPipeInputStream then it's definitely alright.  OTOH, we do copy
the memory, right?  I was somehow hoping that you just expose the
IPC-allocated buffers via your own implementation of nsIInputStream,
avoiding coping to an XPCOM pipe.

That would be nice, but no.  IPC doesn't even support passing dependent
strings as far as I know.

This first iteration is just an actor like any other.  I didn't change the
IPC internals at all.

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

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On Fri, May 20, 2016 at 11:09 AM, Ben Kelly <bke...@mozilla.com> wrote:

> On Fri, May 20, 2016 at 7:37 AM, Honza Bambas <hbam...@mozilla.com> wrote:
>
>> And I do! :)  Actually any parent necko channel, mainly HTTP, which sends
>> data to the child process.  We also have bug 1110596 which complains about
>> too much memory copying in that code.
>> Could your IPCStream be used for that?
>>
>
> Yes, I think that could work in general.
>
> I think the main issue would be compat with existing nsIStreamListeners.
> These listeners might be written such that they expect the nsIInputStream
> passed in OnDataAvailable() to return their entire length from a single
> Available() call.  This will not be true for a streamed pipe.
>

Actually, the nsIStreamListener interface explicitly requires a fixed
length nsIInputStream:

"The onDataAvailable impl must read exactly |aCount| bytes of data before
returning."

From:

https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl#18

I don't think we can use a pipe-oriented stream here without changing that
interface contract.

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

Re: Redesigning the docshell/loadgroup/document interaction

[Ben Kelly]

On May 20, 2016 6:14 PM, "Jonas Sicking"  wrote:
> That doesn't sound good. We should give each worker its own loadgroup.
> Independent of if it's a dedicated, shared or service worker.
>
> Or is there a reason to share loadgroup with the document that I'm
missing?

Not sure.  I think it's been that way for a long time.  I just added the
code to create a load group if we didn't get one from the document.

I thought the load group was related to the tab child because the group has
notification callbacks, etc.

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

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On Sat, May 21, 2016 at 2:05 PM, Ben Kelly <bke...@mozilla.com> wrote:

>
> On May 21, 2016 9:44 AM, "Honza Bambas" <hbam...@mozilla.com> wrote:
> > If it's nsPipeInputStream then it's definitely alright.  OTOH, we do
> copy the memory, right?  I was somehow hoping that you just expose the
> IPC-allocated buffers via your own implementation of nsIInputStream,
> avoiding coping to an XPCOM pipe.
>
> That would be nice, but no.  IPC doesn't even support passing dependent
> strings as far as I know.
>
> This first iteration is just an actor like any other.  I didn't change the
> IPC internals at all.
>
Oh, I think understand better now.  I wrote a bug to implement this idea in
the future:

https://bugzilla.mozilla.org/show_bug.cgi?id=1274815

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

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On Fri, May 20, 2016 at 7:37 AM, Honza Bambas  wrote:

> And I do! :)  Actually any parent necko channel, mainly HTTP, which sends
> data to the child process.  We also have bug 1110596 which complains about
> too much memory copying in that code.
> Could your IPCStream be used for that?
>

Yes, I think that could work in general.

I think the main issue would be compat with existing nsIStreamListeners.
These listeners might be written such that they expect the nsIInputStream
passed in OnDataAvailable() to return their entire length from a single
Available() call.  This will not be true for a streamed pipe.

I'll try to get some patches ready to test with in the next couple weeks
and we can see.  Worst case we could do the accumulation into a string in
the child process to avoid spiking memory in the parent process.

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

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On Thu, May 19, 2016 at 1:41 PM, Andrew McCreight <amccrei...@mozilla.com>
wrote:

> On Thu, May 19, 2016 at 8:04 AM, Ben Kelly <bke...@mozilla.com> wrote:
>
> > 3) Supports async pipe streams using a new PSendStream actor from
> > *child-to-parent*.  I have plans to add support for parent-to-child, but
> I
> > don't have a consumer yet and we need to figure out some issues with
> > PBackground targeting worker threads.
> >
>
> One place that this would be very useful would be for networking. Right
> now, the various networking protocols send data to the child by calling
> NS_ReadInputStreamToString(), then copying the string into an IPC message,
> which is bad because it requires a lot of contiguous memory addresses, and
> also has a fair bit of bloat from all of the copies (bug 1110596, bug
> 1263028).
>
> Andrew
> ___
> 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: IPCStream landed in mozilla-central

[Ben Kelly]

On Thu, May 19, 2016 at 1:41 PM, Andrew McCreight <amccrei...@mozilla.com>
wrote:

> On Thu, May 19, 2016 at 8:04 AM, Ben Kelly <bke...@mozilla.com> wrote:
>
> > 3) Supports async pipe streams using a new PSendStream actor from
> > *child-to-parent*.  I have plans to add support for parent-to-child, but
> I
> > don't have a consumer yet and we need to figure out some issues with
> > PBackground targeting worker threads.
> >
>
> One place that this would be very useful would be for networking. Right
> now, the various networking protocols send data to the child by calling
> NS_ReadInputStreamToString(), then copying the string into an IPC message,
> which is bad because it requires a lot of contiguous memory addresses, and
> also has a fair bit of bloat from all of the copies (bug 1110596, bug
> 1263028).
>

That would be a good thing to try.  I wonder how many consumers assume
nsIChannel::OnDataAvailable() provides a fixed length stream, though.

Here is the bug to track parent-to-child pipe streaming:

https://bugzilla.mozilla.org/show_bug.cgi?id=1274343

Thanks.

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

Re: Intent to implement and ship: allow-popups-to-escape-sandbox sandbox flag

[Ben Kelly]

On Thu, May 5, 2016 at 10:48 PM, Boris Zbarsky  wrote:

> Support in other browsers: I believe Chrome supports this.  I'm not sure
> what the state is in other browsers.
>

Looks like chrome 46:

https://www.chromestatus.com/feature/5708368589094912

I'm happy to see this implemented since I've had web developers ask about
it in the past.  I think anything we can do to get more ads running in
sandboxed iframes is a good thing.

Thanks!

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

Re: PSA - With e10s enabled, initial browser in new windows will soon be remote by default

[Ben Kelly]

Mike,

Do we still kill the child process if the last content tab is closed?  For
example, close all tabs in all windows except for an about:memory tab or
something.  Or do we keep the child process alive as long as the
browser.xul window is alive?

Keeping the process alive would actually make a few things easier with our
current service worker/push/devtools setup.

Thanks.

Ben

On Mon, Jul 25, 2016 at 10:29 AM, Mike Conley  wrote:

> After much toil, this has finally landed on central. Hopefully it sticks.
>
> Big thanks to all of my reviewers - especially smaug, who reviewed the bulk
> of the weirder stuff.
>
> -Mike
>
> On 9 June 2016 at 14:21, Mike Conley  wrote:
>
> > If you don’t write tests that open browser windows or work on the
> > front-end of Firefox, you can probably ignore this.
> >
> > The initial browser in browser.xul is non-remote by default. This means
> > that as soon as it browses to some URL that can be loaded in the content
> > process (about:home, for example), we kick off the remoteness flipping
> > machinery that swaps out that initial browser and puts a remote one down
> in
> > its place to load the content in the child process.
> >
> > In bug 1261842, I’m working on switching things around so that the
> initial
> > browser is remote as soon as possible (there’s still some set-up required
> > in JS, so I can’t just add the remote attribute to that initial browser).
> > Doing the flip sooner means we don’t have to set up the content viewer
> for
> > the non-remote browser (which gets immediately destroyed after the
> > remoteness flip), which is good for window-opening performance.
> >
> > Normally, I wouldn’t bother these two mailing lists with this kind of
> > information, but while working on these patches, I’ve had to fix a bunch
> of
> > tests that worked properly under the old assumption (initial browser is
> > non-remote) but not under the new one (initial browser is remote), and I
> > wanted to give a PSA on those writing tests that open windows.
> >
> > Here’s the deal: If you’re writing browser mochitests and you need to
> open
> > a window, please use BrowserTestUtils.openNewBrowserWindow. If you need
> to
> > trigger window openings via another mechanism (like window.open in
> > content), but need to do things with the newly opened window, set up a
> > Promise with BrowserTestUtils.waitForNewWindow. Both of these methods are
> > doing the right thing in terms of waiting for the new window to set
> itself
> > up and for the initial browser to be ready to do things with it.
> >
> > If you care - here’s why: without them, you run the risk of falling into
> > the mistake I was seeing in a number of tests, which was opening a new
> > window, waiting for its load event, telling the initial browser to load
> > some URI, and then waiting for BrowserTestUtils.browserLoaded to resolve
> > before proceeding. This technique will fail frequently, because sometimes
> > the message to load the URI will arrive at content after it has loaded
> its
> > initial about:blank, but before the parent has had an opportunity to hear
> > that the initial about:blank has been loaded. This means that the
> > browserLoaded Promise will sometimes resolve even though the URI you
> > requested hasn’t finished (or maybe even started) loading.
> >
> > Anyhow, with the patches in the bug, I appear to have fixed all of the
> > tests that fall into this trap - but if you write a new test that’s
> opening
> > a window that’s failing frequently and you don’t know why, it might be
> > because you need to use those BrowserTestUtils methods.
> >
> > Feel free to follow up with me in this thread or over IRC if there are
> any
> > questions or concerns regarding bug 1261842.
> >
> > Thanks,
> >
> > -Mike
> >
> ___
> 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

PSA: enabling auto-shutdown and restart of osfile async worker on nightly

[Ben Kelly]

Hi all,

Please be aware I'm going to try enabling this pref on nightly later today:

osfile.reset_worker_delay

This will allow us to clean up the osfile async worker when its not in use
to save system resources.  It will then automatically restart the worker
the next time its needed.

This is only being enabled on non-release builds right now until we can
show that it doesn't cause any regressions.  Talos and try are green, but
its possible there are unknown race condition bugs.

See this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1279389

If you have any issues with the osfile async methods on nightly/aurora,
please try disabling the pref above.  Also please let me know so that I can
investigate why it broke.

Thanks.

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

Re: PSA: enabling auto-shutdown and restart of osfile async worker on nightly

[Ben Kelly]

This is live in today's nightly.  Again, please let me know if you run into
problems.

Thanks!

Ben

On Tue, Jun 28, 2016 at 3:01 PM, Ben Kelly <bke...@mozilla.com> wrote:

> Hi all,
>
> Please be aware I'm going to try enabling this pref on nightly later today:
>
> osfile.reset_worker_delay
>
> This will allow us to clean up the osfile async worker when its not in use
> to save system resources.  It will then automatically restart the worker
> the next time its needed.
>
> This is only being enabled on non-release builds right now until we can
> show that it doesn't cause any regressions.  Talos and try are green, but
> its possible there are unknown race condition bugs.
>
> See this bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1279389
>
> If you have any issues with the osfile async methods on nightly/aurora,
> please try disabling the pref above.  Also please let me know so that I can
> investigate why it broke.
>
> Thanks.
>
> Ben
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to disable service workers and push in 52 ESR

[Ben Kelly]

I just filed:

https://bugzilla.mozilla.org/show_bug.cgi?id=1338144

On Thu, Feb 9, 2017 at 4:26 AM, Kohei Yoshino <kohei.yosh...@gmail.com>
wrote:

> Do we already have a bug for this? Firefox 52 will be shipped just in 4
> weeks.
>
>
> On 2017-01-18 10:49 AM, Ben Kelly wrote:
>
>> I'd like to disable service workers in 52 ESR.  This would also require
>> disabling push notifications.
>>
>> A year ago we decided to disable service workers in 45 ESR because it was
>> very new and unstable:
>>
>> https://groups.google.com/forum/#!msg/mozilla.dev.platform/
>> yuNHtDhl3lY/VWXOa8N9AgAJ
>>
>> While things have stabilized since then we are in process of making a
>> major
>> architectural change in order to support multiple content processes
>> (multi-e10s).  This will make it very difficult to uplift fixes.  Once the
>> new architecture has stabilized we should be able to enable SW in the next
>> ESR.
>>
>> Thoughts?
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to disable service workers and push in 52 ESR

[Ben Kelly]

On Wed, Jan 18, 2017 at 10:58 AM, Dirkjan Ochtman <dirk...@ochtman.nl>
wrote:

> On Wed, Jan 18, 2017 at 4:49 PM, Ben Kelly <bke...@mozilla.com> wrote:
> > While things have stabilized since then we are in process of making a
> major
> > architectural change in order to support multiple content processes
> > (multi-e10s).  This will make it very difficult to uplift fixes.  Once
> the
> > new architecture has stabilized we should be able to enable SW in the
> next
> > ESR.
> >
> > Thoughts?
>
> Maybe I'm missing context, but I find the notion of not-shipping
> things on ESR that are available on the normal release channel pretty
> strange. Maybe this is because I'm incorrectly assuming that the
> majority of Firefox usage in the wild is not on ESR? Alternatively, is
> Service Workers the only thing getting major architectural changes for
> multi-e10s? (I would assume not.) If not, are we withholding all those
> other things from the ESR channel, too?
>

Last I checked we do this all the time for new and potentially unstable
things.  For example, AFAIK we do not enable e10s on ESR.  I have not heard
if that will change for 52 ESR.  I would expect not, though, since we are
still rolling it out to the full population.

I just don't think we can commit to providing stable security uplifts to
ESR for a 9 months if our trunk version is completely different.

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

Re: Intent to disable service workers and push in 52 ESR

[Ben Kelly]

On Wed, Jan 18, 2017 at 10:58 AM, Till Schneidereit <
t...@tillschneidereit.net> wrote:

> That'll mean that Windows XP/Vista users won't have them.
>
> Might be ok, but means the bar for a decision like this should be somewhat
> higher than usual, I think.
>

Understood, but that does not change the difficulty of trying to maintain
ESR for 9+ months when trunk code looks completely different.  I think its
too risky from a security maintenance perspective.

Also, service workers are typically a progressive enhancement for most
sites.  Users still have access to content on the web.  They just lose
offline support and push notification alerts.

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

Re: Intent to disable service workers and push in 52 ESR

[Ben Kelly]

On Wed, Jan 18, 2017 at 1:35 PM, Dirkjan Ochtman  wrote:

> API. On the other hand, sites like caniuse.com clearly advertise that
> ServiceWorkers are available in Firefox (and Chrome), and then going
> back and not exposing that in the ESR population seems to me that in a
> sense, we break a kind of contract with web developers.
>

This situation already exists with 45 ESR.  Sites that hard code caniuse.com
with UA sniffing are already broken.

They are also broken in private browsing mode because we don't support
service workers there either.

Sites generally feature detect service workers because safari does not
implement them yet.  The entire API has been designed to work well with
feature detection and progressive enhancement.


> What's the rate of ServiceWorker security bugs? Do you expect that many of
> them?
>

I don't have exact numbers.  But there have been many uplifts for service
workers.  In general it is helpful that we have been able to mark these as
45esr:disabled.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to disable service workers and push in 52 ESR

[Ben Kelly]

Hi all,

I'd like to disable service workers in 52 ESR.  This would also require
disabling push notifications.

A year ago we decided to disable service workers in 45 ESR because it was
very new and unstable:

https://groups.google.com/forum/#!msg/mozilla.dev.platform/yuNHtDhl3lY/VWXOa8N9AgAJ

While things have stabilized since then we are in process of making a major
architectural change in order to support multiple content processes
(multi-e10s).  This will make it very difficult to uplift fixes.  Once the
new architecture has stabilized we should be able to enable SW in the next
ESR.

Thoughts?

Thanks.

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

Re: Intent to implement and ship: isSecureContext attribute on workers

[Ben Kelly]

On Sep 23, 2016 9:15 PM, "Boris Zbarsky"
> Concerns: No one else implements this so far, and it does add one
interesting requirement: it requires that shared workers not be shared
between secure and insecure contexts.  Whichever one creates the shared
worker first wins; the other creation attempt throws.  It _may_ be better
to have an error event here instead of an exception (akin to what we do for
origin mismatches on the worker url).  It may also turn out that not
creating the shared worker in this situation creates a compat issue...  So
far I haven't been able to figure out a sane way to test whether Chrome
does the shared worker thing (which it might do even though it doesn't
implement the DOM API).

Some spec discussion for this is here btw:

https://github.com/w3c/webappsec/issues/406

To be honest I don't love the order dependent nature of this.  If I had my
druthers I'd rather just restrict `new SharedWorker()` to secure contexts
completely.  If you can't use the API from insecure contexts the problem
goes away.

Given some people think SharedWorker can be removed completely, it might
not even be a compat problem.  (Safari removed SharedWorker and no one
noticed...)

By the same argument, though, I should probably just not worry about this
API corner case.

So looks good to me.

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

Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case

[Ben Kelly]

I wrote a test using fetch() that seems to suggest we don't re-use
in-progress requests at the http cache level.

(Note, this downloads about 200MB... don't click on your mobile.)

https://people.mozilla.org/~bkelly/fetch/http-cache/

On Wed, Sep 7, 2016 at 1:45 PM, Andrew Sutherland <
asutherl...@asutherland.org> wrote:

> There's a proposal at https://github.com/jakearchibald/background-cache
> for enabling persistently-tracked uploads/downloads in the background.  It
> might change names to background-fetch.
>
> I'm interested in getting some informed feedback about the following
> use-case on https://github.com/jakearchibald/background-cache/issues/3
>
> A motivating use-case is for a site that wants to download movies/podcasts
> in the background and keep them around for offline purposes.  Once the file
> is downloaded, it seems clear that the (ServiceWorker [DOM]) Cache API[1]
> is a great place to store the result.  What's less clear is how best to
> handle allowing the user to begin watching the movie when the download is
> still in-progress.  A potential straw-man is:
>
> * Start the download with background-fetch
> * Use the background-fetch API to track the status of the download.  When
> there's "enough" downloaded, start playing the video via its online URL
> with the confidence that the netwerk cache2 can unify the two requests as
> much as possible.
> * When the download completes, stick the movie in the DOM Cache API and
> use Cache-furnished Responses for all future playback requests.
>
> The greatest concern right now is around range requests and redundantly
> downloaded data.  We've seen interest in the Service Worker repo issues for
> the ability to track/match in-flight fetch requests[2] that I hope should
> be entirely mooted by the HTTP cache.  Depending on the HTTP cache until
> the download is complete ideally avoids redundant downloads, but it would
> be great to have reassurance and an understanding of how a background-fetch
> download mechanism might interact with the HTTP cache.  Could the download
> entirely use the HTTP cache for storage with the cache entries pinned to
> avoid eviction until the download notification extendable event completes?
>
> Andrew
>
> 1: https://w3c.github.io/ServiceWorker/spec/service_worker/
> index.html#cache-objects
> 2: https://github.com/w3c/ServiceWorker/issues/959
>
> ___
> 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 unship: WorkerGlobalScope.onclose

[Ben Kelly]

https://bugzilla.mozilla.org/show_bug.cgi?id=790919

On Mon, Aug 29, 2016 at 11:42 AM, Eric Shepherd 
wrote:

> Is there a bug for this? If so, please be sure it's got the
> dev-doc-needed keyword. Thanks!
>
> 
> *From:* Andrea Marchesini
> *Sent:* Monday, Aug 22, 2016 4:03:40 AM EDT
> *To:* dev-platform
> *Subject:* Intent to unship: WorkerGlobalScope.onclose
>
> > I'm planning to remove |partial interface WorkerGlobalScope {  attribute
> > EventHandler onclose; }|.
> > This EventHandler has been in our code base since ever but it's not part
> of
> > the Workers spec and no other browses implement it.
>
> --
>
> Eric Shepherd
> Senior Technical Writer
> Mozilla Developer Network 
> Blog: https://www.bitstampede.com/
> Twitter: http://twitter.com/sheppy
> Doodle: http://doodle.com/the.sheppy
>
> ___
> 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: PSA: some setTimeout()/setInterval() changes

[Ben Kelly]

On Thu, Oct 27, 2016 at 1:26 PM, Mike Taylor <mi...@mozilla.com> wrote:

> On 10/27/16 10:08 AM, Ben Kelly wrote:
>
>> The short story is that there should be very minimal observable
>> difference.
>>
>
> How do these changes compare with other browsers behavior (for the
> web-observable effects)? Do you have any idea?


I honestly don't know how other browsers handle these edge cases.

I believe, however, our previous behavior of "freezing time" during a sync
xhr was unspec'd and probably unexpected.  I don't see anything in
xhr.spec.whatwg.org about shifting timers around.

The html spec references the "pause" concept for alert() modals:

https://html.spec.whatwg.org/#pause

Again, this says nothing specific about running pending code synchronously
when you leave the modal state.  It even encourages experimentation around
mitigating the impact of the modal on user experience.

Not sure if that helps or not.  I tend to believe these changes won't have
a large compat impact since timers are already rather imprecise and can be
delayed for a number of reasons.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: More setTimeout()/setInterval() changes

[Ben Kelly]

Hi all,

FYI, I've landed some more timer changes in FF52 nightly.  This builds on
the work previously discussed here:

  https://groups.google.com/forum/#!topic/mozilla.dev.platform/obJ97zzl4Po

As of today's nightly setTimeout() and setInterval() will more aggressively
yield the main thread back to other work in the browser.

What does this mean?

1) If your page typically only fires a few timers or timers spread over
time you should see no change.
2) If your page fires many timers that try to execute at once and the
browser is idle, you should see no change.
3) If your page fires many timers that try to execute at once and the
browser is busy, you may see some timers delayed a bit more than previous
versions of FF.
3) The order of timer callbacks should not be effected.

In addition, if we detect a page is generating many more timer callbacks
than can be processed by the browser we will temporarily suspend the page
until the main thread can catch up.

These restrictions only apply to content windows and not chrome windows.

Please let me know if you run into any problems from these changes.

Thanks.

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

Re: Heads Up: Snappy library upgraded

[Ben Kelly]

On Tue, Oct 25, 2016 at 5:03 AM, Jan Varga  wrote:

> Since the integration of bug 768074 [1] ​in Nightly, the new version of
> the library is used. The library is used in IndexedDB, DOM cache, etc.
> We are confident that the library is fully backwards-compatible and we
> have an xpcshell test that restores a profile created in FF 11 (the version
> when IDB introduced compression of structured clone data).
>

Note, however, this is another case where if someone upgrades their profile
by running it in nightly, and then tries to bring the profile back to an
older version like release, things will break.  The old snappy code is not
forward-compatible with the new version.

Some discussion on how to deal with these things in bug 1246615:

https://bugzilla.mozilla.org/show_bug.cgi?id=1246615
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: some setTimeout()/setInterval() changes

[Ben Kelly]

Hey all,

Just FYI, I've landed a refactoring of how we suspend our timers in:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1303167

The short story is that there should be very minimal observable
difference.  The main changes you might see are:

1) Previously we shifted timers during things like sync xhr.  This made it
seem like "time stood still" for those timers.  If you had a timer in 1
second and did a sync xhr for 0.5 seconds, then the timer would fire 1
second after the sync xhr.

Now we don't shift timers and allow "time to pass" during things like sync
xhr.  So if you have a timer in 1 second and do a sync xhr for 0.5 seconds
then the timer will fire 0.5 seconds after the sync xhr.

2) When a modal dialog was closed we used to synchronously run all timers
that might have fired during the modal state.  We now fire these timers
asynchonously.  In addition, they may be subject ot the background timer
throttling.  So these timers will be slightly delayed compared to
previously behavior.

3) We now suspend timers in all child windows when a chrome modal dialog is
shown.  Previously it was possible for content windows to continue to run
timers when a chrome modal was open.  There was only a single test that
this change impacted.  This change makes the behavior consistent between
content and chrome modal dialogs.

The bug has all the gory details, but this change cleans up an error-prone
API and a secondary way of stopping timers.  We now have a single method
for suspending and resuming timers.

Please let me know if you run into any problems from these changes.

Thanks.

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

Re: Intent to ship: requestIdleCallback

[Ben Kelly]

I think we need to fix this issue as well.  I think it could probably be
uplifted before requestIdleCallback() hits release, though.

https://bugzilla.mozilla.org/show_bug.cgi?id=1315260

On Thu, Nov 3, 2016 at 4:01 PM, Andreas Farre  wrote:

> As of 2016-11-7 I intend to turn requestIdleCallback on by default
> (with the condition that
> https://bugzilla.mozilla.org/show_bug.cgi?id=1314314 has landed). It
> has been developed behind the dom.requestIdleCallback.enabled
> preference. Other UAs shipping this or intending to ship it are Chrome
> (shipping), Edge (public support).
>
> This feature was previously discussed in this "intent to implement"
> thread: https://groups.google.com/forum/#!msg/mozilla.dev.
> platform/q6AQnTEeX6o/dqS48DbtAwAJ
>
> Bug to turn on by default: https://bugzilla.mozilla.org/
> show_bug.cgi?id=1314959
>
> Link to standard: https://w3c.github.io/requestidlecallback/
>
> Since 'Intent to Implement' was sent mainly clarifications of the spec
> have been added. Differences standing out are:
>
> * Callbacks are associated with Window instead of Document
> * Opening up for future additions of scheduling strategies
> * Added privacy section explaining how the fingerprinting of
> requestIdleCallback is no worse than fingerprinting of
> requestAnimationFrame
>
> Cheers,
> Andreas
> ___
> 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: Some recent crash-stats improvements

[Ben Kelly]

Does the "raw dump" tab support require special permissions?  I don't see
any way to download the memory report from:

https://crash-stats.mozilla.com/report/index/1a572047-ac64-4add-a82f-a31512161004#tab-rawdump

On Sun, Oct 9, 2016 at 7:51 PM, Nicholas Nethercote 
wrote:

> Greetings,
>
> crash-stats.mozilla.org has had some recent improvements that are
> worth highlighting.
>
> - There is new documentation on how to search through crash reports:
> https://developer.mozilla.org/en-US/docs/A_guide_to_
> searching_crash_reports.
> You might think you already know how to do this, but crash-stats'
> functionality for *grouping* search results is powerful and easy to
> overlook, so this page is worth reading to make sure you understand it
> fully. This documentation is linked to from the Super Search page
> within crash-stats.
>
> - Some crash reports contain memory reports. (The
> "ContainsMemoryReport" field is set in that case.) It used to be
> difficult to download this memory report, but thanks to Peter
> Bengtsson it's now much easier -- when a memory report is present,
> there's now a link to it from the "Raw Dump" tab of an individual
> crash report. See
> https://crash-stats.mozilla.com/report/index/1a572047-
> ac64-4add-a82f-a31512161004#tab-rawdump
> for an example.
>
> - Also, something that is not in crash-stats but is closely related:
> Marco Castellucio's new crash tools at
> https://mozilla.github.io/stab-crashes/. There are several tools, but
> probably the most widely-applicable one is
> https://mozilla.github.io/stab-crashes/correlations.html, which finds
> correlations for a particular crash signature. It works much better
> than the existing correlations tool within crash-stats. If you have a
> crash for which the cause is not obvious, this tool can be enormously
> helpful -- e.g. bug 1307029 is for a generic-looking crash signature
> that turns out to be highly correlated with a particular extension.
>
> Nick
> ___
> 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 Implement: Private Browsing Storage (IndexedDB, Blobs, etc)

[Ben Kelly]

On Tue, Dec 13, 2016 at 7:35 PM, Kyle Machulis 
wrote:

> AFAIK, Chrome's strategy for this is to just store everything in memory and
> keep a fairly small size cap on it (something like 32mb?).
>

Really?  Last I asked they said they basically created a new temporary
profile when entering incognito mode.  (More similar to our containers,
etc.) The code then worked as normal.  So I thought it wrote to disk.  They
then delete the temp profile when they are done with incognito.

This is only based on an informal face-to-face discussion with one of their
storage engineers, though.  I haven't actually looked at the code.

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

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 11:14 AM, Boris Zbarsky  wrote:

> OK, so how would one use this API in practice?


if (navigator.connect.downlinkMax > 100) {
  // perform low-priority background downloads
}
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 3:28 AM, Andrea Marchesini 
wrote:

> Our implementation of the NetworkInformation interface does not follow the
> latest version of the spec. I'm planning to work on it. Then, I would like
> to enable this interface by default - currently it's behind pref.
>

I think we do enable it by default on android, but not desktop.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 12:06 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:

> On 12/15/16 11:23 AM, Ben Kelly wrote:
>
>> if (navigator.connect.downlinkMax > 100) {
>>   // perform low-priority background downloads
>> }
>>
>
> Why is the downlinkMax the right thing to be checking here, though? Again,
> outside of the "cellphone on a cell network" case, the last-hop bandwidth
> tells you pretty much nothing because it's incredibly unlikely that the
> last hop is the bottleneck.
>

Its more information than nothing.  And saying its a limit on the maximum
is accurate.  And its a value that can become more accurate over time with
better OS and network integration.  Code using the API gets that for free
without changing anything.  If it special cases on "cellular" or "wifi",
then it has to update its list if a new networking type is introduced in
the future.

I agree that for the "cellphone on a cell network" case the last-hop
> bandwidth can be useful.


Bluetooth networking is also a thing.

I think being able to distinguish this stuff provides some value even if
its not perfect for all cases.  And I don't see how it causes any harm.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 8:42 AM, Boris Zbarsky  wrote:

> On 12/15/16 3:28 AM, Andrea Marchesini wrote:
>
>> Spec: https://w3c.github.io/netinfo/
>>
>
> Is there any plan to have this turned into an actual spec, complete with
> IPR commitments, testcases, wider review, etc?
>

What is an IPR commitment?

It seems we can implement WPT tests.  I don't know what you consider "an
actual spec", but I imagine if we show interest in implementing it will
graduate from WICG to its own w3c repo.


> Have we done a privacy review of this spec?  Why should a webpage ever
> know whether I'm connected via "ethernet" vs "wifi" (insofar as we have any
> way to determine this at all; I could be connected via "ethernet" to a
> bridge that is connected via "wifi")?
>

We are shipping the connection type information on android already.  Since
FF32 as far as I can tell.

The downlink max bandwidth would be just a lookup table from the type info
in our implementation.  It could be improved in the future, of course.

Also, I'm not sure how transient data like connection type really helps
with fingerprinting too much compared to the other info already available
to fingerprint.


> Looking at the use cases document at  etinfo-usecases/>, it seems like people generally care more about things
> like "bandwidth costs money" and "how much bandwidth do we expect?" than
> about the actual physical transport, no?
>

The spec is pretty clearly written to specify maximum possible downlink
given the first hop interface.  It does not make any claims about actual
total throughput.  I personally don't agree APIs like this need to provide
perfect information to provide value.

So, while I think we should implement this, I do have one concern.  We have
been shipping a `typechange` event on this API while the spec and chrome
use a `change` event.  If we start firing `change` as well, do we need to
still fire `typechange` for back-compat?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows CPU power settings

[Ben Kelly]

On Mon, Dec 12, 2016 at 8:44 PM, Gregory Szorc  wrote:

> The Windows 10 power settings appear to set the minimum CPU frequency at 5%
> or 10% of maximum. When I cranked this up to 100%, artifact build time
> dropped from ~170s to ~77s and full build configure dropped from ~165s to
> ~97s!
>
> If you are a Windows user with Xeons in your desktop, you may want to visit
> Control Panel -> Hardware and Sound -> Power Options -> Edit Plan Settings
> -> Change advanced power settings -> Process power management -> Minimum
> processor state and crank that up and see what happens. Note: running your
> CPU at 100% all the time may impact your power bill!
>

FWIW, in my windows 10 Control Panel -> Hardware and Sound -> Power Options
I had 3 preset power profiles:

* Balanced (default selected)
* Power Saver
* Performance

The "Balanced" profile has the 5% minimum clock speed.  The "Performance"
profile set that to 100%.

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

Re: Rust required to build Gecko

[Ben Kelly]

I tried ./mach bootstrap on a fresh m-c this morning and got:

Will try to install Rust.
Downloading rustup-init... Error running mach:

['bootstrap']

The error occurred in code that was called by the mach command. This is
either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this
error
message.

The details of the failure are as follows:

URLError: 


On Thu, Dec 15, 2016 at 7:28 PM, Ralph Giles  wrote:

> Today we've pushed the change to enable rust language code by default
> in Firefox builds. The changes are on the autoland branch right now,
> so this will affect your builds from mozilla-central or gecko-dev
> starting tomorrow. This brings our default developer build in line
> with what we've been doing with official builds. Thanks to everyone
> who helped make this happen.
>
> As a reminder, you'll now need `rustc` and `cargo` in the PATH of your
> build environment, just like with python and the C/C++ compiler. You
> can install rust with `./mach bootstrap`. After that you can stay on
> the latest stable release by running `rustup update` every 6 weeks or
> so. If you want more control I recommend manually running the
> installer and update tool from https://rustup.rs/
>
> More information about using Rust code in Firefox can be found at
> https://developer.mozilla.org/en-US/Firefox/Building_
> Firefox_with_Rust_code
>
> Cheers,
>  -r
>
>
> On Thu, Nov 24, 2016 at 2:49 PM, Ralph Giles  wrote:
> > tl;dr This is a heads-up that all gecko developers should install rust.
> >
> > Next week I plan to switch our default build config to require Rust
> > when building Firefox.[1] If you compile Firefox from the C++ source,
> > please install the Rust language environment now.
> >
> > You can install Rust by running `./mach bootstrap` which will download
> > and run the rustup installer for you.[2]
> >
> > We recommend the installer at https://rustup.rs/ (despite being beta)
> > because it makes staying up to date and cross-compilation easy. If you
> > want more control, or to experiment with rust, you can install
> > directly from that website.
> >
> > The main thing is to have up-to-date versions of the `rustc` and
> > `cargo` executables in the path of your build shell. Rust releases
> > every six weeks, just like Firefox, and we generally require the
> > latest stable release to compile mozilla-central. You can stay current
> > by running `rustup update`.
> >
> > You'll still be able to build without a rust compiler by adding:
> >
> >   ac_add_options --disable-rust
> >
> > to your mozconfig. This is a temporary work-around; we expect to
> > remove that option and require Rust unconditionally early next year as
> > non-optional features start to depend on it.
> >
> > Rust language in Gecko is an important part of Project Quantum. I'm
> > excited to be taking this next step toward that future. We first
> > shipped Rust code to users in Firefox 48, so it's long past time this
> > aspect of our default builds matched what we release.[3]
> >
> > Thanks for your attention,
> >  -r
> >
> > [1] Enabling rust is https://bugzil.la/1283898
> > [2] bootstrap support landed Tuesday in https://bugzil.la/1286799
> > [3] If you have issues with the installer or build, please file issues
> > blocking our tracking bug at https://bugzil.la/oxidation
>
> --
> You received this message because you are subscribed to the Google Groups
> "gecko-all" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gecko-all+unsubscr...@mozilla.com.
> To post to this group, send email to gecko-...@mozilla.com.
> To view this discussion on the web visit https://groups.google.com/a/
> mozilla.com/d/msgid/gecko-all/CA%2Brf4XK6cuhDPk%
> 2B39o6SLgRpCZ9z%3DepgugEzpuB_SW0hJ05a8w%40mail.gmail.com.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: GCC 4.9 now required to build on Linux/Android

[Ben Kelly]

FWIW, it seems ./mach bootstrap does not install gcc 4.9 on ubuntu 14.04.

On Fri, Dec 23, 2016 at 11:08 AM, Nathan Froyd  wrote:

> Bug 1322792 has landed on inbound, which changes configure to require
> GCC 4.9 to build; our automation switched over to GCC 4.9 for our
> Linux builds earlier this week.  (Android builds have been using GCC
> 4.9 for some time.)
>
> This change paves the way for being able to compile in C++14 mode for
> all of our Tier-1 platforms, which in turn unlocks using some C++14
> features in our codebase:
>
> * binary literals
> * digit separators
> * generic lambdas
> * initialized lambda captures
> * return type deduction (not quite sure if we want to use this feature
> widely)
>
> We did not upgrade to GCC 5 for ABI compatibility reasons (GCC 5
> changed the libstdc++ ABI); we did not upgrade to GCC 6 for the same
> reason and because Gecko still has a few issues with GCC 6 (bug
> 1316555 tracks).
>
> Thanks,
> -Nathan
> ___
> 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: unowned module: Firefox::New Tab Page, help me find an owner

[Ben Kelly]

On Wed, Mar 22, 2017 at 10:00 AM, David Burns <dbu...@mozilla.com> wrote:

> On 22 March 2017 at 13:49, Ben Kelly <bke...@mozilla.com> wrote:
>
>> Finding someone to own the feature and investigate intermittents is
>> important too, but that doesn't mean the tests have zero value.
>>
>
> This just strikes me that we are going to disable until they are all gone
> then we have dead code in the tree and still no one to own it. Its a longer
> process that could end up at the same end point.
>

Are *all* the tests intermittent?  My quick read of the bug was that its a
single test.  I just don't understand the logic of *removing green tests*
from the tree.  The idea they might one day become intermittent is not
compelling to me.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: unowned module: Firefox::New Tab Page, help me find an owner

[Ben Kelly]

On Wed, Mar 22, 2017 at 9:22 AM,  wrote:

> I have not been able to find an owner for the Firefox::New Tab Page
> bugzilla component (bug 1346908).  There are 35 tests in the tree and
> without anyone to assume responsibility for them when they are intermittent
> (bug 1338848), I plan to delete them all if I cannot get an owner by the
> end of the month including someone who will sign up to be the triage owner
> for the bugzilla component.
>

You plan to delete all the tests?  This seems somewhat extreme for a
shipped feature.  Why not disable just the tests that are intermittent?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: unowned module: Firefox::New Tab Page, help me find an owner

[Ben Kelly]

On Wed, Mar 22, 2017 at 9:39 AM, <jma...@mozilla.com> wrote:

> On Wednesday, March 22, 2017 at 9:35:35 AM UTC-4, Ben Kelly wrote:
> > You plan to delete all the tests?  This seems somewhat extreme for a
> > shipped feature.  Why not disable just the tests that are intermittent?
>
> I agree that does sound extreme, but if nobody cares about the tests or
> will accept responsibility if we have failures, then they have no real
> value.  I assume they have value and this is why I am asking for help to
> find someone who cares about the code and will take responsibility for the
> feature and related tests.
>

I don't agree they have no value "if nobody cares about the tests or will
accept responsibility if we have failures".  If someone changes something
in platform and these tests turn perma-red, that person has to fix their
code.  This is how we prevent regressions.

Finding someone to own the feature and investigate intermittents is
important too, but that doesn't mean the tests have zero value.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Better download security through browsers

[Ben Kelly]

We now have SRI and support integrity attributes on elements like

Re: e10s-multi update and tests

[Ben Kelly]

On Wed, Mar 22, 2017 at 9:12 PM, Andrew McCreight 
wrote:

> On Wed, Mar 22, 2017 at 6:00 PM, Nicholas Nethercote <
> n.netherc...@gmail.com
> > wrote:
>
> > Do we have a clear definition of "content process"? I.e. does/will it
> > include:
> >
> > - GMP processes (no?)
> > - GPU process (probably not?)
> > - file:// URL processes (probably should?)
> > - Web Extensions processes (probably should?)
> > - ServiceWorker processes (probably should?)
> >
>
> The most operational definition is that a content process is a process
> where XRE_IsContentProcess() returns true. From the enum GeckoProcessType,
> you can see the various other possibilities. So the answers to your
> questions are then probably that GMP and GPU are not, but the others are.
> Though maybe you are asking which processes count against the limit of 4.
>

FWIW, the intention is that the worker process would not count against the
limit.  It would not contain any windows and would be significantly smaller
in size.

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

Re: windows build anti-virus exclusion list?

[Ben Kelly]

On Fri, Mar 17, 2017 at 3:40 PM, Ted Mielczarek  wrote:

> Yeah, the JS engine uses a lot more complex C++ features than the rest of
> the code in our tree, so it takes longer to compile. This is also why the
> `FILES_PER_UNIFIED_FILE` setting is lower in js/src than the rest of the
> tree. We do try to build js/src pretty early in the build, although the
> exact workings of the compile tier is not something I currently understand.
> One thing we could try here would be to hack up some instrumentation to
> record the time taken to compile each source file, which would let us
> determine if we need to tweak `FILES_PER_UNIFIED_FILE` lower, at least.
>

Hmm.  The "we do try to build js/src pretty early in the build" statement
doesn't seem to match what I am seeing.  Its one of the last things to
build on my machine.  Also, it seems to be serialized with building other
libraries.

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

Re: windows build anti-virus exclusion list?

[Ben Kelly]

On Fri, Mar 17, 2017 at 1:36 PM, Ted Mielczarek  wrote:

> Back to the original topic, I recently set up a fresh Windows machine
> and I followed the same basic steps (enable performance power mode,
> whitelist a bunch of stuff in Windows Defender) and my build seemed
> basically CPU-bound[1] during the compile tier. Disabling realtime
> protection in Defender made it *slightly* better[2] but didn't have a
> large impact on the overall build time (something like 20s out of ~14m
> total for a clobber).
>

The 14min measurement must have been for a partial build.  With defender
disabled the best I can get is 18min.  This is on one of the new lenovo
p710 machines with 16 xeon cores.

I definitely observed periods where it was not CPU bound.  For example, at
the end of the js lib build I observed a single cl.exe process sit for ~2
minutes while no other work was being done.  I also saw link.exe take a
long time without parallelism, but i think that's a known issue.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: windows build anti-virus exclusion list?

[Ben Kelly]

On Fri, Mar 17, 2017 at 2:52 PM, Ben Kelly <bke...@mozilla.com> wrote:

> On Fri, Mar 17, 2017 at 2:43 PM, Ted Mielczarek <t...@mielczarek.org>
> wrote:
>
> Yeah, I specifically meant "CPU-bound during the compile tier", where we
>> compile all the C++ code. If you look at the resource usage graphs I
>> posted it's pretty apparent where that is (the full `mach
>> resource-usage` HTML page has a nicer breakdown of tiers). The stuff
>> before and after compile is not as good, and the tail end of compile
>> gets hung up on some long-pole files, but otherwise it does a pretty
>> good job of saturating available CPU. I also manually monitored disk and
>> memory usage during the second build, and didn't see much there. The
>> disk usage showed ~5% active time, presumably mostly the compiler
>> generating output, and memory usage seemed to be stable at around 9GB
>> for most of the build (I didn't watch during libxul linking, I wouldn't
>> be surprised if it spikes then).
>>
>
> That "long pole file" at the end of the js lib is over 10% of my compile
> time.  That's not very good parallelism in the compile stage IMO.
>

This is the part of the build I'm talking about:

15:17.80 Unified_cpp_js_src8.cpp
15:17.90 Unified_cpp_js_src38.cpp
15:18.33 Unified_cpp_js_src40.cpp
15:19.96 Unified_cpp_js_src41.cpp
15:21.41 Unified_cpp_js_src9.cpp
16:59.13 Interpreter.cpp
16:59.15 js_static.lib
16:59.99 module.res
17:00.04 Creating Resource file: module.res
17:00.81 StaticXULComponentsStart.cpp
17:00.99 nsDllMain.cpp

For the 1:38 between Unified_cpp_js_src9.cpp and Interpreter.cpp only a
single cl.exe process is running.  I guess thats closer to 8% of the total
build time.  Still seems very weird to me.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: windows build anti-virus exclusion list?

[Ben Kelly]

On Fri, Mar 17, 2017 at 2:43 PM, Ted Mielczarek  wrote:

> > The 14min measurement must have been for a partial build.  With defender
> > disabled the best I can get is 18min.  This is on one of the new lenovo
> > p710 machines with 16 xeon cores.
>
> Nope, full clobber builds: `./mach clobber; time ./mach build`. (I have
> the same machine, FWIW.) The svg files I uploaded were from `mach
>

Sorry.  I misread.  I thought you were referring to my earlier email about
dropping from 20+ minutes to 14 minutes.  My 14 minute measurement was
erroneous.  I seem to get 18 minute clobber builds.


> Yeah, I specifically meant "CPU-bound during the compile tier", where we
> compile all the C++ code. If you look at the resource usage graphs I
> posted it's pretty apparent where that is (the full `mach
> resource-usage` HTML page has a nicer breakdown of tiers). The stuff
> before and after compile is not as good, and the tail end of compile
> gets hung up on some long-pole files, but otherwise it does a pretty
> good job of saturating available CPU. I also manually monitored disk and
> memory usage during the second build, and didn't see much there. The
> disk usage showed ~5% active time, presumably mostly the compiler
> generating output, and memory usage seemed to be stable at around 9GB
> for most of the build (I didn't watch during libxul linking, I wouldn't
> be surprised if it spikes then).
>

That "long pole file" at the end of the js lib is over 10% of my compile
time.  That's not very good parallelism in the compile stage IMO.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: windows build anti-virus exclusion list?

[Ben Kelly]

On Thu, Mar 16, 2017 at 11:26 PM, Ben Kelly <bke...@mozilla.com> wrote:

>   - mozilla-build install dir
>   - visual studio install dir
>   - /users/bkelly/appdada/local/temp
>   - /users/bkelly (because temp dir was not enough)
>

FWIW, adding all these extra exclusions dropped my build time from ~22
minutes to ~14 minutes.

I'm hoping I can narrow my home directory exclusion down to things like
.bash_profile, .cargo, etc.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

windows build anti-virus exclusion list?

[Ben Kelly]

Hi all,

I'm trying to configure my new windows build machine and noticed that
builds were still somewhat slow.  I did:

1) Put it in high performance power profile
2) Made sure my mozilla-central dir was not being indexed for search
3) Excluded my mozilla-central directory from windows defender

Watching the task monitor during a build, though, I still saw MsMpEng.exe
(antivirus) running during the build.

I ended up added some very broad exclusions to get this down close to
zero.  I am now excluding:

  - mozilla-central checkout
  - mozilla-build install dir
  - visual studio install dir
  - /users/bkelly/appdada/local/temp
  - /users/bkelly (because temp dir was not enough)

I'd like to narrow this down a bit.  Does anyone have a better list of
things to exclude from virus scanning for our build process?

Thanks.

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

Re: windows build anti-virus exclusion list?

[Ben Kelly]

On Thu, Mar 16, 2017 at 11:40 PM, Michael Hoye <mh...@mozilla.com> wrote:

> Depending on your AV, if you don't exempt mozilla-central some of our
> tests will get quarantined and you won't be able to build at all.
>

I guess I was hoping someone familiar with our build might know the answer.
:-)

In any case, I managed to narrow my exclusions down to:

c:\devel
c:\mozilla-build
c:\program files\microsoft visual studio 12.0
c:\users\bkelly\.bash_profile
c:\users\bkelly\.cargo
c:\users\bkelly\.multirust
c:\users\bkelly\.rustup

And then in my .bash_profile I did this to avoid having to exclude all of
%TEMP%:

export TMP=/c/devel/.tmp
export TEMP=$TMP
export TMPDIR=$TMP

I couldn't figure out how to re-map /tmp in msys.  The fstab was not
working for me.

I guess if that all seems reasonable I can try to add some text to the wiki
suggesting it:

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites

Thanks.

Ben


>
> - mhoye
>
>
> On Mar 16, 2017 20:34, "Ben Kelly" <bke...@mozilla.com> wrote:
>
> On Thu, Mar 16, 2017 at 11:26 PM, Ben Kelly <bke...@mozilla.com> wrote:
>
> >   - mozilla-build install dir
> >   - visual studio install dir
> >   - /users/bkelly/appdada/local/temp
> >   - /users/bkelly (because temp dir was not enough)
> >
>
> FWIW, adding all these extra exclusions dropped my build time from ~22
> minutes to ~14 minutes.
>
> I'm hoping I can narrow my home directory exclusion down to things like
> .bash_profile, .cargo, etc.
> ___
> 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: windows build anti-virus exclusion list?

[Ben Kelly]

On Fri, Mar 17, 2017 at 12:05 AM, Ben Kelly <bke...@mozilla.com> wrote:

> On Thu, Mar 16, 2017 at 11:40 PM, Michael Hoye <mh...@mozilla.com> wrote:
>
> Depending on your AV, if you don't exempt mozilla-central some of our
>> tests will get quarantined and you won't be able to build at all.
>>
>
> I guess I was hoping someone familiar with our build might know the
> answer. :-)
>

Sorry.  I think I replied to the wrong person here.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please write good commit messages before asking for code review

[Ben Kelly]

On Thu, Mar 9, 2017 at 5:48 PM, Eric Rescorla <e...@rtfm.com> wrote:

>
>
> On Thu, Mar 9, 2017 at 2:43 PM, Ben Kelly <bke...@mozilla.com> wrote:
>
>> (Just continuing the thread here.)
>>
>> Personally I prefer looking at the bug for the full context and single
>> point of truth.  Also, security bugs typically can't have extensive commit
>> messages and moving a lot of context to commit messages might paint a
>> target on security patches.
>>
>
> Can't you determine that by just looking to see if the bug is visible?
>

So you are saying we should just write SECURE BUG REDACTED in these commit
messages now?  Or do we have to fabricate a paragraph to match other
commits now?

Right now our security bug process asks about the commit message and if it
"paints a target" on the patch.  If you want to change our commit message
policy, please adjust that or take it into account.

And I also agree with the other commenters here that complexity should be
described in code comments.

Ultimately as long as the code is explained via comments, the bug is
up-to-date, and our secure bug process isn't broken I don't have a strong
opinion here.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please write good commit messages before asking for code review

[Ben Kelly]

On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey  wrote:

> On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote:
> > I review a large number of patches on a typical day, and usually I have
> to
> > spend a fair amount of time to just understand what the patch is doing.
> As
> > the patch author, you can do a lot to help make this easier by *writing
> > better commit messages*.  Starting now, I'm going to try out a new
> practice
> > for a while: I'm going to first review the commit message of all patches,
> > and if I can't understand what the patch does by reading the commit
> message
> > before reading any of the code, I'll r- and ask for another version of
> the
> > patch.
>
> Sometimes, the commit message does explain what it does in a sufficient
> manner, but finding out why requires reading the bug, assuming it's
> written there. I think this information should also be in the commit
> message.


(Just continuing the thread here.)

Personally I prefer looking at the bug for the full context and single
point of truth.  Also, security bugs typically can't have extensive commit
messages and moving a lot of context to commit messages might paint a
target on security patches.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: All the processes

[Ben Kelly]

On Fri, Mar 3, 2017 at 7:15 PM, Nicholas Nethercote 
wrote:

> Do I have any of these details wrong? Have I missed any?
>

We plan to ship a "worker" process that will run ServiceWorker (and
eventually SharedWorker) threads as part of:

https://bugzilla.mozilla.org/show_bug.cgi?id=1231208

In the future we may optionally schedule workers in other content
processes, but we are aiming for a separate process to start for a couple
reasons.  It ensures we have no accidental dependencies on running in the
same process as the content page.  It also helps us work around perf issues
with many operations requiring the main thread which is often busy during
page load in content processes.

I also think it would be worth investigating a separate process for the
network stack:

https://bugzilla.mozilla.org/show_bug.cgi?id=1322426

I don't think anyone is working on that, though.

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

Re: All the processes

[Ben Kelly]

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 processes without
> blowing it out too badly, but 8 would be a major problem.
>

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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Heads Up: /storage upgraded from version 1.0 to 2.0

[Ben Kelly]

On Tue, Mar 7, 2017 at 6:09 PM, Xidorn Quan  wrote:

> > This major version change is downgrade-incompatible, so IndexedDB and
> > DOM cache won't work in an older version if their profile has been
> > upgraded.
> > IndexedDB is also used internally, so stuff that depends on it likely
> > won't work too.
> > There's bug 1246615 [2] where you can find a discussion related to this
> > issue.
>
> It would probably be a good idea to backup the old files when upgrading,
> so that old version can at least pick the backup file to use.
>

Maintaining downgrade compatibility is a lot more complex than people think
and we have zero test support for it.  It hasn't been safe for *years*
(look at IDB db migration code history) and its not going to be safe unless
we want to invest a lot in it.  We just need to do bug 1246615 to make FF
warn when a power user gets themselves into this unsupported mode.
Per-channel profiles like dev-edition would be great too.

As an example of why "backup the db" is harder than it sounds, you would
need to backup the entire storage subsystem.  If you lose data in IDB, but
don't lose data in other sub-systems like cache API, then an origin can
find itself in a corrupted state.  If we allows writes at this point it can
permanently wedge itself in a corrupted state.  From the perspective of
preserving user data its much safer to simply refuse to open the storage
system when we detect an incompatibility like this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: A reminder about commit messages: they should be useful

[Ben Kelly]

On Mon, Apr 17, 2017 at 9:21 PM, Nicholas Nethercote  wrote:

> > That is why we have links to the bug. Bug should always be the unite of
> > truth telling
> > why some change was done. Bugs tend to have so much more context about
> the
> > change than any individual commit message can or should have.
>
> With all due respect, I think you have a different view on this to at least
> some people (and perhaps most people).
>

FWIW I agree with Olli.  I look for a good one line summary of the change,
but beyond that I find you really do need to look at the bug to get the
full context.

I don't object to people writing longer commit messages, but that
information needs to be in the bug.  Our tools today (splinter and
mozreview) don't do that automatically AFAIK.  I think there is an hg
extension you can get to do it with splinter.

I find it much more useful to have an explanatory comment in the bug since
I can see it in context with everything else, links, etc.  Its also clear
what version of the patch its associated with.  Commit messages often are
not updated with changes to the patch and can be slightly wrong.

Finally, as has been mentioned in previous threads, any real nuance should
be in the patch itself as comments.

Both bugs and code comments are searchable and more easily discoverable.
The tools for finding information in blame are much harder to use.  I
greatly prefer bug and code comments.

Just my two cents.  (I wasn't going to chime in here, but felt compelled
since Olli's view was being cast as rare.)

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

Re: disabled non-e10s tests on trunk

[Ben Kelly]

On Tue, Aug 15, 2017 at 4:37 PM, Joel Maher  wrote:

> All of the above mentioned tests are not run on Android (well
> mochitest-media is to some degree).  Is 4 months unreasonable to fix the
> related tests that do not run in e10s?  Is there another time frame that
> seems more reasonable?
>

Last I checked it was your team that told me WPT on android was not an
immediate priority.  The WPT harness itself does not run there.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: disabled non-e10s tests on trunk

[Ben Kelly]

On Tue, Aug 15, 2017 at 4:43 PM, Joel Maher  wrote:

> This is a discussion about tests in e10s mode, not WPT on Android.
>

Yes.  And android is our last tier 1 platform that requires non-e10s.  I
think that makes it relevant to the discussion.


>
> What specific coverage are we missing by not running WPT in non-e10s mode
> on desktop?  When can we ensure we have that coverage in e10s mode?  I
> assume this is just making sure the tests that we have disabled on e10s
> mode need to get fixed.
>

Some features are implemented completely differently in e10s vs non-e10s
mode.  The main one I am aware of is service workers.  If you turn on
non-e10s WPT tests there will be regressions.

Don't get me wrong.  I'd prefer not to deal with non-e10s either.  But its
*absolutely false* to say we don't need to support it right now because its
required for a tier 1 platform.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: disabled non-e10s tests on trunk

[Ben Kelly]

On Tue, Aug 15, 2017 at 4:29 PM,  wrote:

> While there are many tests which individually are disabled or lacking
> coverage, these test suites have no non-e10s coverage:
> * web-platform-tests
> * browser-chrome
> * devtools
> * jsreftests
> * mochitest-webgl, mochitest-gpu, mochitest-media
> * reftest un-accel
>
> I would propose running these above tests on windows7-opt (we don't have
> these running yet in windows 10, although we are close), and only running
> specific tests which are not run in e10s mode, turning them off December
> 29th, 2017.
>
> Keep in mind we have had many years to get all our tests running in e10s
> mode and we have known since last year that Firefox 57 would be the first
> release that we ship e10s by default to our users- my proposal is a 4 month
> temporary measure to let test owners finish ensuring their tests are
> running in e10s mode.
>

WPT tests do not run on android.  Unless we can get WPT tests running on
android, I don't think dropping all non-e10s coverage for them is
reasonable.  I don't know of any plan to move android to e10s by Dec 29.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Ben Kelly]

Chris,

Do you know who controls this blog post?

https://blog.mozilla.org/firefox/firefox-64-default-64-bit-windows/

The chart is really misleading.  What does the vertical bar chart for
"security" even mean?  As noted on twitter:

https://twitter.com/kylealden/status/897222041476005888

The bar chart for "crashes" at least has an intelligible y-axis, but it
seems wrong.  The chart shows more like a 60% improvement instead of a 39%
improvement.

Perhaps we should just replace this graphic with an up-arrow for security
and a down-arrow for crashes?

Anyway, sorry to be pedantic, but misleading charts are kind of a pet peeve.

Thanks.

Ben

On Wed, Jul 19, 2017 at 2:38 AM, Chris Peterson 
wrote:

> We are on track to make 64-bit Firefox the default build for Win64 OS,
> bringing improved ASLR and fewer OOM crashes to the 70% of Windows Firefox
> users running Win64.
>
> PLANS:
>
> * In Firefox 55 (August 8), the Windows stub installer will default to
> 64-bit Firefox for eligible users (Win64 and 2+ GB RAM).
>
> * In Firefox 56 (September 26), we will migrate existing eligible 32-bit
> Firefox users to 64-bit. About 70% of Windows Firefox users currently run
> 32-bit Firefox build on Win64. Nearly all of these users can be migrated to
> 64-bit Firefox.
>
> Our Win64 project wiki has more details about the long road to making
> 64-bit Firefox the default:
>
> https://wiki.mozilla.org/Firefox/Win64
>
> PROGRESS:
>
> * David Parks fixed the insidious Flash video streaming bug affecting
> Xfinity and MLB! (bug 1334803)
>
> * Bob Owen fixed the sandbox issue that prevented 64-bit Firefox from
> being run from a network-mounted drive! (bug 1377555)
>
> * Some highlights from week 2 of our Firefox 54 experiment comparing 32-
> and 64-bit Firefox users:
>
> - About 8% of Windows users have <= 2 GB RAM!
>
> - User retention and engagement metrics (session length, # of pages, # of
> tabs) are about the same for 32- and 64-bit Firefox users, regardless of
> memory size.
>
> - 64-bit content process crash rate is about the same as 32-bit for users
> with 2 GB and about 20% less with 2+ GB!
>
> - 64-bit browser process crash rate is about the same as 32-bit for users
> with 2 GB and about 20% less with 2+ GB!
>
> - 64-bit plugin process crash rate is about 50% less than 32-bit for users
> with 2 GB and 80% less with 2+ GB!
>
> We are still considering whether 64-bit Firefox should have a default
> minimum memory requirement. As a placeholder value, Firefox 55 currently
> requires 2+ GB, but based on the results of our experiment, we may remove
> the minimum memory requirement. Microsoft's minimum memory require for
> Win64 itself is 2 GB, so anyone running Win64 with less than 2 GB is having
> a bad time.
> ___
> 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: disabled non-e10s tests on trunk

[Ben Kelly]

On Tue, Aug 8, 2017 at 5:18 PM, Ben Kelly <bke...@mozilla.com> wrote:

> On Tue, Aug 8, 2017 at 5:12 PM, <jma...@mozilla.com> wrote:
>
>> In bug 1386689, we have turned them off.  There was some surprise in
>> doing this and some valid concerns expressed in comments in the bug.  Given
>> that, I thought we should bring this information to a wider audience on
>> dev.platform so more developers are aware of the change.
>>
>> While we get some advantages to not running duplicated tests (faster try
>> results, less backlogs, fewer intermittent failures) there might be
>> compelling reasons to run some tests in e10s based on specific coverage.
>> With that said, I would like to say that any tests we turn on as non-e10s
>> must have a clearly marked end date- as in this is only a temporary measure
>> while we schedule work in to gain this coverage fully with e10s tests.
>>
>
> If we have an android test disabled (a lot I think), then we should
> consider continuing to run the test in non-e10s on desktop linux.  Having
> more real devices to run android tests on would probably reduce the number
> of tests that are disabled.  The emulator is extremely slow and not
> representative of real hardware.
>

BTW, we have a large corpus of tests that don't run on android at all:
WPT.  Increasingly over time features are only covered by WPT tests.

I think we should keep at least non-e10s running on linux or linux64 for
now until we can improve our android test coverage or move android to e10s.

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

Re: Firefox and clang-cl

[Ben Kelly]

On Mon, Aug 14, 2017 at 6:11 AM, Till Schneidereit <
t...@tillschneidereit.net> wrote:

> On Mon, Aug 14, 2017 at 9:27 AM, Julian Seward  wrote:
>
> > On 13/08/17 03:40, Ehsan Akhgari wrote:
> > > As you may have heard by now, Chromium has started to switch their
> > Windows
> > > builds to use clang-cl instead of MSVC [1].  This has improved their
> > > Speedometer v2 benchmark score on x86 (but not on x86-64) by about 30%
> > > according to AWFY [2].  [..]
> >
> > Do we have any insight into why the Clang version is so much faster?
> > 30% strikes me as a large difference for two supposedly mature optimizing
> > compilers.  And stranger still that it applies only for the 32-bit case.
> > So I'm curious to know what's changed.
> >
>
> AFAICT, the real change is about 19%: shortly before the jump to ~103,
> their score regressed from 86 to 78. I think using 86 as the baseline makes
> much more sense. 19% is obviously still a substantial improvement from a
> compiler change.
>

Google ran a bisect on the regression and improvements.  Here is some
explanation of the regression:

https://bugs.chromium.org/p/chromium/issues/detail?id=749359#c4

The comment suggests that the change would see an improvement in clang
since the code would then use class "overflow builtins".

Its hard to tell if all of the clang-on-windows improvement is due to this
same set of code or not.

The bisects were run from this issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=750672#c12

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

Re: Response.body streams landing on trunk, default off

[Ben Kelly]

FYI, the Fetch API side of streams has landed and is now in nightly.
Please test and file bugs.  Thanks!

Ben

On Thu, Aug 10, 2017 at 11:29 PM, Ben Kelly <bke...@mozilla.com> wrote:

> Hi all,
>
> As some of you may know :till and :baku have been working hard to
> implement ReadableStream support.  Till landed the js bits in bug 1272697:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1272697
>
> Andrea has been working on the DOM integration with Fetch API in bug
> 1128959:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1128959
>
> This second bug is now on inbound and looks like its going to stick
> (famous last words...).  Hopefully it will be in trunk tomorrow and in
> Saturday's nightly.
>
> Please note that streams will be disabled by default for now.  There are a
> few more issues to address before we can enable it by default.
>
> If you would like to test Response.body please enable these two prefs:
>
>   javascript.options.streams
>   dom.streams.enabled
>
> Please test and file any bugs you might find. I've done some local testing
> on a few sites I'm aware of that use streams and so far I have not found
> any functional problems.
>
> Many thanks to Till and Andrea for their hard work on streams!
>
> Ben
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linking with lld instead of ld/gold

[Ben Kelly]

On Sun, Aug 13, 2017 at 5:08 PM, Sylvestre Ledru 
wrote:

> To use it, you should have a clang >= 4.0 installed and lld installed
> on the system.
> clang is in charge of the LLD detection with its option -fuse-ld=lld
> (this option is also supported by gcc since version 6). Clang will
> look for the same version of LLD available on the system.
>

The clang installed by ./mach bootstrap in .mozbuild is 3.9.0.  Is there
any plan to update that to >= 4.0?

Thanks.

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