W3C Proposed Recommendations: WebAssembly

2019-10-04 Thread L. David Baron 
A set of W3C Proposed Recommendations are available for the membership of
W3C (including Mozilla) to vote on, before they proceed to the final
stage of being a W3C Recomendation:

  WebAssembly Core Specification
  https://www.w3.org/TR/wasm-core-1/
  https://webassembly.github.io/spec/core/bikeshed/

  WebAssembly JavaScript Interface
  https://www.w3.org/TR/wasm-js-api-1/
  https://webassembly.github.io/spec/js-api/

  WebAssembly Web API
  https://www.w3.org/TR/wasm-web-api-1/
  https://webassembly.github.io/spec/web-api/

  Deadline for responses: Sunday, October 27, 2019

If there are comments you think Mozilla should send as part of the
review, please say so in this thread.  Ideally, such comments should
link to github issues filed against the specification.  (I'd note,
however, that there have been previous opportunities to make
comments, so it's somewhat bad form to bring up fundamental issues
for the first time at this stage.)

I think we should probably explicitly support these specifications
given our involvement.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: Fennec

2019-10-04 Thread Nicholas Alexander 
Hi all,

On Thu, Sep 19, 2019 at 12:56 PM James Willcox  wrote:

> Folks,
>
> As you may be aware, Fennec has been frozen on 68 ESR with the expectation
> that Fenix will become the new Firefox for Android in 2020. For reasons of
> hygiene and simplification, I propose that we begin removing Fennec from
> mozilla-central as soon as feasible. There are a few known blockers
> currently being tracked under bug 1582218. If you know of any other issues,
> please let me know and/or file blockers.
>
> Obviously, we will not be removing anything related to GeckoView. This
> means that mobile/android/geckoview/, MOZ_WIDGET_ANDROID, etc. will all be
> sticking around. Only the Fennec frontend and any platform code that needed
> to disambiguate Fennec from GeckoView at runtime[0] will be targeted.
>

I just queued landing Bug 1580356
 which removes Fennec
(Firefox for Android) build support, source code, and various hangers on.
A Nightly-simulation try build was happy

so hopefully it sticks.

Please file follow-up depending on that ticket and blocking Bug 1582218
.

Good night and good luck,
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding windows and docshells leaked until shutdown

2019-10-04 Thread Greg Tatum 
I started a section on dealing with leaks on the MDN mochitest page. Feel
free to contribute to it with any tips that may be useful to others. I got
pointed to this thread when I was asking for some help on leaks yesterday.
I couldn't find any details when searching online for anything around the
"leakcheck" mechanism, so I figured docs would be good to add.

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Mochitest#Diagnosing_and_fixing_leakcheck_failures

On Thu, Oct 3, 2019 at 6:10 AM smaug  wrote:

> On 10/3/19 1:18 AM, Andrew McCreight wrote:
> > On Wed, Oct 2, 2019 at 2:35 PM Geoff Lankow 
> wrote:
> >
> >> Hi all, I need some advice.
> >>
> >> I'm trying to enable Mochitest on debug builds of Thunderbird. It works
> >> fine, except for the leak check, which finds a number of leaked windows
> >> and docshells. Obviously we don't want to leak these things, but I can't
> >> find what's holding onto them.
> >>
> >> I've ruled out a number of likely candidates and I'm quickly running out
> >> of ideas. Can you offer any tips or tricks that might help?
> >>
> >> Here's an example log:
> >>
> >>
> https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=267576044=try-comm-central=8051
> >
> >
> > What this leak checker means is that a docshell or window was created
> while
> > the test was running, but was not destroyed until after the test finished
> > (and we ran a bunch of GCs and CCs). However, these docshells and windows
> > don't show up in the leakcheck output, which means that they were cleaned
> > up before we shut down.
>
> Ah, good, runtime leak :)
> Runtime leaks are in general way easier to debug than leaks which are
> there until shutdown.
> Add a conditional break point to the Release method of the relevant object
> and see all the cases Release is called. One (or more) of the Release
> calls ends
> up revealing where the leak is coming from.
>
> To get access to the right C++ object, CC log is one way to get the
> address.
>
>
>
> >
> > A typical cause for these is that there's some top level data structure,
> > often in JS but it could be in C++, too, that keeps track of every
> docshell
> > or window that is created, and does so by just adding a reference to it.
> > When we start shutdown, the data structure gets torn down, and we don't
> > leak things forever.
> >
> > One small tip is that if you look at the line after the "leaked until
> > shutdown" message and you'll see something like this:
> > [task 2019-09-20T03:42:16.942Z] 03:42:16 INFO - TEST-INFO |
> > comm/calendar/test/browser/browser_calendarList.js | windows(s) leaked:
> > [pid = 1155] [serial = 38], [pid = 1155] [serial = 36], [pid = 1155]
> > [serial = 39], [pid = 1155] [serial = 37]
> >
> > The entries like "[pid = 1155] [serial = 38]" are the descriptors we use
> > for windows (and docshells have a similar thing). If you search for
> "[pid =
> > 1155] [serial = 38]" in the log, you can see where exactly each window
> was
> > created and destroyed. Sometimes that can give a hint about what is going
> > wrong.
> >
> > Like Emilio said, the best approach to fixing these leaks is going to be
> > getting GC/CC logs from the point where it complains about the window
> being
> > alive, and then you can figure out from there what is keeping the window
> > alive, which may or may not point at what the leak is.
> >
> > In practice, doing all of this leak fixing is rather a big project by
> > itself, so I'd recommend that you disable this leak checking in
> Thunderbird
> > somehow, and then just try to get the rest of the debug tests up and
> > running, and then maybe come back to it later. This leak checking is done
> > in this file (by doing postprocessing of the browser log):
> > testing/mochitest/leaks.py
> >
> >
> >
> >>
> >> GL
> >> ___
> >> 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 prototype: Web Share Target

2019-10-04 Thread David Burns 
On Fri, 4 Oct 2019 at 03:30,  wrote:

>
>
> Web-platform-tests: requires manual tests.
>

Is this something that we could be tested with testdriver.js inside wpt?

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

Re: Intent to ship: MediaRecorder.{audio|video}BitsPerSecond

2019-10-04 Thread Andreas Pehrson 
On Fri, Oct 4, 2019 at 6:54 AM Tom Ritter  wrote:

> It's a bit hard for me to tell from the description - are these values
> dependent on a user's hardware, performance of the user's computer, or
> a user-chosen setting?  If so we would want to support
> resistFingerprinting.
>

The spec allows the UA to base them on anything it sees fit, if the
application leaves it
to the UA to decide. Our implementation uses fixed and application-provided
values, per below.

There are three different modes of configuring these values for an
application, and here's how we set them:
1) Application did no configuration at all: we use hardcoded values:
2.5Mbps for video and 128kbps for audio
2) Application configured audio and video respectively: we use the provided
values
3) Application configured a total bitrate: Our implementation has a fixed
algorithm for this -- its only inputs
is the number of tracks and kinds of tracks, and the total bitrate
configured is distributed according to a
weighting where a video track gets 20 times as high a bitrate as audio, and
they're capped within fixed limits.
(see https://phabricator.services.mozilla.com/D41585#C1663069NL43 for the
limits, and
https://phabricator.services.mozilla.com/D41585#C1663069NL212 for the
algorithm)

Given this, I don't see the need for explicit resistFingerprinting support.

-tom
>
> On Thu, Oct 3, 2019 at 9:54 PM Andreas Pehrson 
> wrote:
> >
> > As of Oct 4th I intend to land and ship the audioBitsPerSecond and
> > videoBitsPerSecond attributes of MediaRecorder on all platforms. We've
> > shipped MediaRecorder since Firefox 29.
> >
> > *Summary*: The audioBitsPerSecond and videoBitsPerSecond attributes of
> > MediaRecorder reflect what an application has configured the
> MediaRecorder
> > to use (and which we already ship support for doing). In case it was
> > configured with a total (audio+video) bitrate, or if it was not
> configured
> > at all, these attributes reflect what the UA has chosen to configure the
> > MediaRecorder with.
> >
> > After starting a recording, these are again updated to reflect the
> current
> > configuration of the MediaRecorder, since tracks are now known and the UA
> > may have recalculated the chosen bitrates based on the number and kind of
> > tracks that are being recorded.
> >
> > At the same time I'm making our MediaRecorder implementation largely
> > spec-compliant. There's work in bug 1514158 as well as bug 1512175, where
> > the former is focusing on these attributes and the latter focuses on mime
> > type handling. We landed spec clarifications for both of these recently.
> >
> > *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1514158
> >
> > *Standard*:
> >
> https://w3c.github.io/mediacapture-record/MediaRecorder.html#dom-mediarecorder-videobitspersecond
> > Clarifications were made to the spec to make this more interoperable.
> These
> > were approved by Google.
> https://github.com/w3c/mediacapture-record/pull/175
> >
> > *Platform coverage*: All
> >
> > *Preference*: There is no special pref for these attributes
> >
> > *DevTools bug*: There is no generic devtools support for MediaRecorder
> >
> > *Other browsers*:
> > Chrome shipped (since 49, bug:
> > https://bugs.chromium.org/p/chromium/issues/detail?id=262211),
> > Safari shipped MediaRecorder but no attributes yet (behind an
> experimental
> > feature flag since TP73, bug:
> https://bugs.webkit.org/show_bug.cgi?id=85851)
> >
> > *web-platform-tests*: I'm adding one as part of bug 1514158:
> > https://phabricator.services.mozilla.com/D41584
> >
> > *Secure contexts*: No, MediaRecorder is historically not restricted to
> > secure contexts. However some APIs for getting access to the
> > MediaStreamTracks needed to create a recorder are.
> >
> >
> > Andreas Pehrson
> > ___
> > 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