Re: Intent to implement and ship: support ::cue pseudo-element from document.

[Chris Pearce]

On Wednesday, March 29, 2017 at 11:21:06 PM UTC+13, bec...@mozilla.com wrote:
> Summary:
> We are going to support ::cue(with no argument) pseudo-element for webvtt.
> It allows styling the webvtt subtitle/caption text during video playback.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1318542
> 
> Spec: https://w3c.github.io/webvtt/#the-cue-pseudo-element
> 
> Platform coverage:
> All platforms
> 
> Estimated or target release:
> Firefox 55
> 
> Preference:
> media.webvtt.pseudo.enabled, default is true.
> 
> DevTools bug:
> None.
> 
> Do other browser engines implement this?
> Yes, chrome, safari, opera
> 
> Web Developer Use-Cases:
> write the ::cue style block in the document, then ::cue rules will be applied 
> to the .vtt subtitle. Note that the ::cue style block can only appear in 
> document, not in vtt file (not support yet).
> 
> ::cue {
>   ...
> }
> 
> 
>  
> 
> 
> Tests:
> web-platform/tests/webvtt/rendering/cues-with-video/processing-model/selectors/*
> Tests under the folder are disabled now, I'm going to enable/fix them.

Excellent. Thanks Benjamin!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: windows build anti-virus exclusion list?

[Gregory Szorc]

On Sun, Mar 26, 2017 at 11:56 PM, Jean-Yves Avenard 
wrote:

> Hi.
>
> I have received the new Dell XPS 15 9560 and got very puzzled as to why
> compiling central was so slow on this machine.
> This is comparing against a Gigabyte Aero 14 with a gen 6 intel CPU
> (2.6Ghz i7-6600HQ) vs Dell's 7th gen (2.8Ghz i7-7700HQ)
> On the Aero 14, compiling central takes 24 minutes. On the XPS 15, first
> go 38 minutes.
> The XPS 15 came with McAfee anti-virus and Windows Defender is disabled.
> An exclusion list made almost no difference. Disabling entirely McAfee: the
> time dropped to 28 minutes.Uninstalling McAfee completely, enabling Windows
> defender with an exclusion list as mentioned in the first post: 26.5 minutes
> Now disabling Windows Defender: not just an exclusion list saw the time
> dropped to 25 minutes.Interestingly, on the Aero disabling Windows Defender
> or having just an exclusion list made almost no difference in compilation
> time. I can't explain the reason. Maybe because big brother is watching all
> the time!
>

The way that A/V scanning typically works on Windows is that the A/V
software inserts a "file system filter driver" into the kernel. This driver
sees pretty much all I/O operations and has the opportunity to change their
behavior, delay their fulfillment (by calling out into a blocking API in
userland), etc.

The file system filter driver for A/V is always installed. Exclusion list
processing needs to be handled by that driver. So just having the driver
installed means there is some overhead. If the exclusion list processing
code is slow, this will slow down I/O, even if a path is in the exclusion
list. From your numbers, I suspect McAfee may have a less optimal exclusion
list processor than Microsoft. That wouldn't surprise me.

You can see which file system filters are loaded by running `fltmc.exe
filters`. Note: you'll have to do this from a command prompt with
administrator access. You'll likely have to plug the names into a search
engine to figure out what they do.

I'm not sure about McAfee, but Windows Defender scans files during the
CloseHandle() API. But only if the file was written or appended to. This
scanning makes CloseHandle() go from ~1us to ~1ms. When you are writing
thousands of files, this scanning can add up! FWIW, Mercurial mitigates
this by having a thread pool that just sits around closing file
descriptors. This change made fresh `hg update` operations on Windows >60s
faster IIRC. I recommend using Process Monitor to record system call times.
That's how I discovered that Windows Defender was mucking about with
CloseHandle(). If you find system calls that other A/V (like McAfee) is
mucking with, we could potentially mitigate their impact in the build
system similar to what Mercurial has done.


> After following the instructions listed there: http://www.
> ultrabookreview.com/14875-fix-throttling-xps-15/
> Compilation time dropped to 23.8 minutes.The main factor was adding
> thermal pads to the MOSFETs.
> Undervolting the CPU by 125mV added 50s of compilation time, but dropped
> the processor temperature by 10C (max 78C vs 68C) and my guess will also
> add quite a lot of battery life.
>

I'll be blunt: you should not be performing full builds on a laptop because
of issues like thermal throttling. Laptops are OK for limited uses (like
traveling). But if you are paid to hack on Gecko, Mozilla should buy you a
desktop. Firefox Desktop developers (who can use artifact builds) can get
away with a laptop for building.


> So if you're in a hurry, you may want to try disabling Windows Defender
> completely.
> FWIW: on those same machines running Linux Ubuntu 16.10;Aero 14: 14
> minutesXPS 15: 13 minutes.That's out of the box, no tweaks of any kinds.
> JY
> ---
> If it ain't broken, please fix it
>
>
>
>
> On Fri, Mar 17, 2017 at 4:26 AM +0100, "Ben Kelly" 
> wrote:
>
>
>
>
>
>
>
>
>
>
> 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: Rationalising Linux audio backend support

[Ralph Giles]

On Wed, Mar 29, 2017 at 3:40 AM, Henri Sivonen  wrote:

> Arguably, system configuration info belongs under FHR, so it would not
> be optimal if the Pulse check wasn't there but was in opt-in Telemetry
> instead. Where was it?

The check was marked opt-out.

https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json#154
https://bugzilla.mozilla.org/show_bug.cgi?id=1280630

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

Re: Rationalising Linux audio backend support

[Jan Beich]

Henri Sivonen  writes:

> It's a problem if distros disable FHR by default

Probably a regression from bug 722240. Did Mozilla contact downstream
maintainers they now have to explicitly opt-in? Bug 1233687 suggests the
answer is "no", favoring one distro over the others.

> or if distros disable the first-run on-boarding UI for opt-in Telemetry.

See bug 667577.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[Jan Beich]

Botond Ballo  writes:

> Anyways, there is no conflict between supporting ALSA and supporting
> 5.1 sound. As has been mentioned earlier in the thread, ALSA has since
> added support for 5.1, and so IIUC it's just our wrapper library
> (libcubeb) that needs the support added.

When did this happen? Bug 1341108 still stands. Try building without
PulseAudio then set media.forcestereo.enabled -> false in about:config.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[Henri Sivonen]

On Wed, Mar 29, 2017 at 12:29 PM, Kurt Roeckx  wrote:
> The FAQ seems to suggest that telemetry is only enabled in the pre-release 
> versions
> and not in the release versions. I assume there is a bias that is caused by 
> this.

There are two types of telemetry: "Firefox Health Report" (enabled by
default) and "Telemetry" (enabled by default in Nightly, Aurora and
Beta but not in release builds).

Arguably, system configuration info belongs under FHR, so it would not
be optimal if the Pulse check wasn't there but was in opt-in Telemetry
instead. Where was it?

It's a problem if distros disable FHR by default or if distros disable
the first-run on-boarding UI for opt-in Telemetry.

In any case, running without telemetry means not having a say in
data-driven decisions about what configurations Mozilla should
support. It's OK to disable telemetry (that's why it's
user-controllable), but both users and distros that make decisions on
users' behalf should to take into account that if don't let Firefox
send info about your system config to Mozilla, your system config is
invisible to Mozilla's decision making about what to support.

> Pulseaudio is really a layer between the application and alsa. If pulseaudio
> can do something it should be possible to do the same with alsa.

It's not that "ALSA can't do this or that" it's "cubeb on top of ALSA
without Pulse in between can't do this or that without additional work
that's already done by Pulse or by cubeb on top of Pulse".

> But maybe pulseaudio makes certain things easier, I don't know.

That PulseAudio makes things easier has been a key point that has been made.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: support ::cue pseudo-element from document.

[bechen]

Summary:
We are going to support ::cue(with no argument) pseudo-element for webvtt.
It allows styling the webvtt subtitle/caption text during video playback.

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

Spec: https://w3c.github.io/webvtt/#the-cue-pseudo-element

Platform coverage:
All platforms

Estimated or target release:
Firefox 55

Preference:
media.webvtt.pseudo.enabled, default is true.

DevTools bug:
None.

Do other browser engines implement this?
Yes, chrome, safari, opera

Web Developer Use-Cases:
write the ::cue style block in the document, then ::cue rules will be applied 
to the .vtt subtitle. Note that the ::cue style block can only appear in 
document, not in vtt file (not support yet).

::cue {
  ...
}


 


Tests:
web-platform/tests/webvtt/rendering/cues-with-video/processing-model/selectors/*
Tests under the folder are disabled now, I'm going to enable/fix them.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MOZ_DEBUG_CHILD_PAUSE is now more flexible

[Jonathan Watt]

The environment variable MOZ_DEBUG_CHILD_PAUSE can now be set to the time in
seconds that you want new content processes to sleep for just after they start
(to give time to attach a debugger). For backwards compatibility, setting the
value to 1 is special and maintains the old behavior of 30s sleep on Mac, 10s
sleep on Windows.

The behavior of MOZ_DEBUG_CHILD_PROCESS is unchanged (30s sleep on Mac; an
NS_DebugBreak() call to prompt you to attach a debugger before the process
continues on Windows).

The priority of the two variables is also unchanged (MOZ_DEBUG_CHILD_PAUSE
overrides MOZ_DEBUG_CHILD_PROCESS on Mac; vice versa on Windows).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[Kurt Roeckx]

On 2017-03-22 19:34, Botond Ballo wrote:

Now that this change has hit the release channel, we've started
receiving feedback from a wider range of users, a lot of it in bug
1345661 [1].

I believe the feedback in that thread brings some new information to
the table that we weren't aware of when this decision was made:

  - Based on the volume of the feedback we received, and the number
of duplicate bugs and so on, it appears that quoted telemetry data
underestimates the number of users who use ALSA. This is
corroborated by the fact that some of the affected distributions
disable telemetry in their Firefox packages.


I was under the impression that the telemetry said it was over 1%. If 
all of those start to report that it's broken, you will get a lot of 
reports. I also thinking breaking more than 1% of the users setup is way 
too high.


I've also reported that certain desktop environments don't come with 
pulseaudio by default.


The FAQ seems to suggest that telemetry is only enabled in the 
pre-release versions and not in the release versions. I assume there is 
a bias that is caused by this.



  - A number of users, particularly those in the audiophile and music
production / recording communities, report technical reasons for
preferring ALSA over PulseAudio.

  - We've had an offer from someone to volunteer to maintain the
ALSA backend (bug 1345661 comment 52 [2]).


Pulseaudio is really a layer between the application and alsa. If 
pulseaudio can do something it should be possible to do the same with 
alsa. But maybe pulseaudio makes certain things easier, I don't know.


In any case, alsa is supported on any linux version, while it's clear 
that for various reasons pulseaudio is not. It makes sense to me to 
support alsa, and maybe only alsa. As I understand it, if you only 
support alsa and the user is using pulseaudio you still end up using 
pulseaudio.



Kurt

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

Re: Rationalising Linux audio backend support

[milasudril]

Den torsdag 14 juli 2016 kl. 09:32:51 UTC+2 skrev Jet Villegas:
> I generally support reducing the support matrix for Linux PCM audio.
> 
> A quick search for "ALSA vs. PulseAudio" comes up with mixed reviews for
> either, which probably explains why we have both. It also seems like we can
> count on ALSA being available on every distro, but perhaps not PulseAudio.
> Can we add some telemetry to measure that?
> 
> Alternatively, you can wire this up so that we only fall back to ALSA
> (stereo) when we can't get PCM audio to route through Pulse.
> 
> --Jet
> 
> On Wed, Jul 13, 2016 at 7:31 PM,  wrote:
> 
> > Supporting two separate audio backends in Linux is duplicated effort.
> >
> > I took over the platform media playback team at Mozilla a little over 3
> > years ago. At that point we only supported WebM/VP8/Vorbis,
> > Ogg/Theora/Vorbis and Wave as well as MP3 on Windows and some additional
> > codecs including MP4/H.264/AAC on a small number of Android phones. At that
> > time most media in the browser ran in Flash.
> >
> > Since then we’ve added words like MP3, MP4, H.264, VP9, Opus, AAC, HE-AAC,
> > MSE and EME to our vocabulary. DASH and HLS are handled by site Javascript
> > using MSE. A massive amount of effort has gone into making everything
> > parallel so we can get as many pixels to the screen as possible. We’re
> > working on platform specific performance improvements on Windows, Linux and
> > Mac. We’re also doing some work to protect ourselves against driver crashes
> > on Windows and Android.
> >
> > We are seeing an explosion of interest in HTML5 video and the accompanying
> > audio is going through libcubeb, our audio backend. We’ve added low latency
> > support to libcubeb for WebAudio and full duplex support so we can use it
> > directly for microphone input for WebRTC.
> >
> > Our official Firefox builds on Linux support both PulseAudio and ALSA.
> > There are a number of additional contributed backends that can be turned on
> > at compile time, although contribution towards long-term maintenance and
> > matching feature parity with the actively developed backends has been low.
> > On Linux, we actively maintain the PulseAudio backend but we also approach
> > the PulseAudio developers when we see issues in PulseAudio. The PulseAudio
> > developers are generally good to work with.
> >
> > The most problematic backend across all platforms is ALSA. It is also
> > missing full duplex support. We are intending to add multichannel (5.1)
> > support across all platforms and the ones that don’t make the cut will be
> > the ALSA backend and the WinMM backend used on Windows XP.
> >
> > Our ALSA backend has fallen behind in features, it is buggy and difficult
> > to fix. PulseAudio is contrastingly low maintenance. I propose
> > discontinuing support for ALSA in our official builds and moving it to
> > off-by-default in our official builds.
> >
> > Leaving all the ALSA code in tree gives people the opportunity to continue
> > maintaining the ALSA backend. Re-enabling it would require bringing it up
> > to the same standard as other backends, not only in terms of current state
> > but also in terms of consistency of contribution.
> >
> > As a long time Linux user, I want to get the most value out of our efforts
> > on Linux. I can do that by focusing our efforts on the things that will
> > have the greatest impact. Sometimes that requires taking a step back and
> > deciding to do one thing well instead of two things poorly.
> >
> > Just to be clear, I’m proposing we stop spending time on ALSA so we can
> > spend that time on adding 5.1 audio support to our PulseAudio backend.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >

There is no PulseAudio vs ALSA. There is only PulseAudio on top of ALSA.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[milasudril]

Den torsdag 14 juli 2016 kl. 04:31:50 UTC+2 skrev ajo...@mozilla.com:
> Supporting two separate audio backends in Linux is duplicated effort.
> 
> I took over the platform media playback team at Mozilla a little over 3 years 
> ago. At that point we only supported WebM/VP8/Vorbis, Ogg/Theora/Vorbis and 
> Wave as well as MP3 on Windows and some additional codecs including 
> MP4/H.264/AAC on a small number of Android phones. At that time most media in 
> the browser ran in Flash.
> 
> Since then we’ve added words like MP3, MP4, H.264, VP9, Opus, AAC, HE-AAC, 
> MSE and EME to our vocabulary. DASH and HLS are handled by site Javascript 
> using MSE. A massive amount of effort has gone into making everything 
> parallel so we can get as many pixels to the screen as possible. We’re 
> working on platform specific performance improvements on Windows, Linux and 
> Mac. We’re also doing some work to protect ourselves against driver crashes 
> on Windows and Android.
> 
> We are seeing an explosion of interest in HTML5 video and the accompanying 
> audio is going through libcubeb, our audio backend. We’ve added low latency 
> support to libcubeb for WebAudio and full duplex support so we can use it 
> directly for microphone input for WebRTC.
> 
> Our official Firefox builds on Linux support both PulseAudio and ALSA. There 
> are a number of additional contributed backends that can be turned on at 
> compile time, although contribution towards long-term maintenance and 
> matching feature parity with the actively developed backends has been low. On 
> Linux, we actively maintain the PulseAudio backend but we also approach the 
> PulseAudio developers when we see issues in PulseAudio. The PulseAudio 
> developers are generally good to work with.
> 
> The most problematic backend across all platforms is ALSA. It is also missing 
> full duplex support. We are intending to add multichannel (5.1) support 
> across all platforms and the ones that don’t make the cut will be the ALSA 
> backend and the WinMM backend used on Windows XP.
> 
> Our ALSA backend has fallen behind in features, it is buggy and difficult to 
> fix. PulseAudio is contrastingly low maintenance. I propose discontinuing 
> support for ALSA in our official builds and moving it to off-by-default in 
> our official builds.
> 
> Leaving all the ALSA code in tree gives people the opportunity to continue 
> maintaining the ALSA backend. Re-enabling it would require bringing it up to 
> the same standard as other backends, not only in terms of current state but 
> also in terms of consistency of contribution.
> 
> As a long time Linux user, I want to get the most value out of our efforts on 
> Linux. I can do that by focusing our efforts on the things that will have the 
> greatest impact. Sometimes that requires taking a step back and deciding to 
> do one thing well instead of two things poorly.
> 
> Just to be clear, I’m proposing we stop spending time on ALSA so we can spend 
> that time on adding 5.1 audio support to our PulseAudio backend.

First, I want to bust these two myths about ALSA. ALSA is the kernel interface 
to the Linux audio subsystem. Thus, if ALSA cannot do stuff, no other library 
can either (unless it is a kernel module). 

1. ALSA does not support full duplex: Wrong: Indeed, it does and JACK requires 
that feature. Otherwise, it cannot be used for step-by-step recording, and 
realtime DSP, which is the whole purpose of JACK. 

2. ALSA does not support 5.1: Wrong: Connect your fat mixer console to the 
computer, start jack, and you will see a lot of inputs and outputs. Why because 
ALSA can record multichannel audio, and also play multichannel audio.

To these two points I want to add that Intel PCH appears to not work in duplex 
mode on ALSA (and thus it would not work on PulseAudio either). But this is 
shitty hardware compared to the real stuff that were build in the 90:s 
(SoundBlaster AWE 64 gold with all connectors you would ever need: Line in, 
Line out, microphone in (+20 dB gain), and MIDI in/out. With right software, 
your home PC was a semi-professional grade music studio).


As a second point, I would like to add a design guide, that should be 
considered before doing any audio programming:

1. There should be one and only one sound server running on the system

2. The sound server should *not* fiddle with sample rates, or anything else 
that requires conversion to frequency domain (such as 5.1 to various surround 
conversions). That should be done by the application internally, or through a 
library. The reason for this is that it adds latency that cannot be removed 
(unless you have a carefully calibrated flux capacitor constructed by Doc Brown 
:-P that pushes the signal back in time). And that boils down to the Heisenberg 
inequality. For those on this list that are more into computer graphics, the 
sample rate of the system should be treated as the refresh rate of the monitor. 
Do the display server convert the 

Re: Async Iteration is available on non-release-only, for testing purpose

[Tooru Fujisawa]

thanks for the input :)

re-landed them disabling on chrome/addon, with a test that checks they're not 
available on chrome code.

--

arai

> 2017/03/28 1:38、Shu-yu Guo のメール:
> 
> Cross-posting to firefox-dev.
> 
> TL;DR:
> 
> arai has done truly excellent feature work implementing the ECMAScript Async 
> Iteration proposal. It is gated to Nightly/DevEd only for content code. We 
> will also be turning off the feature in chrome code to prevent accidental 
> dependence. Both these restrictions will be lifted when the proposal fully 
> matures to be in the next standard.
> 
> PLEASE DO NOT USE ASYNC GENERATORS IN CHROME CODE.
> 
> On Mon, Mar 27, 2017 at 9:31 AM, Shu-yu Guo  wrote:
> I agree that disabling for chrome is the right thing here over prefs. I want 
> Nightly and DevEdition to have stage 3+ TC39 proposals unflagged and ready to 
> play with -- asking folks to turn on prefs to do that is not the way to go 
> here from my perspective.
> 
> Benjamin's concern is legit, though, so let's disable it in chrome.
> 
> On Mon, Mar 27, 2017 at 9:12 AM, Till Schneidereit 
>  wrote:
> I think disabling in chrome code is a good idea. We have done these kinds
> of non-release-only features in the JS engine in the past, and it hasn't
> always gone well precisely for the reasons that have you concerned. OTOH,
> adding a pref is annoyingly complicated for JS engine features (we should
> probably work on that!) and makes the feature much harder to test for web
> developers. Perhaps for now disabling for chrome is really the right
> trade-off?
> 
> On Mon, Mar 27, 2017 at 7:56 AM, Benjamin Smedberg 
> wrote:
> 
> > I am concerned about the accidental consequences of turning this on for
> > nightly/aurora. What if we start writing browser code that relies on these
> > features which unexpectedly starts failing in beta?
> >
> > I presume the value of enabling this in nightly/aurora is that we can get
> > web developers to experiment and report bugs?  Is that something we can do
> > asking them to explicitly turn this on via pref? Or are you worried about
> > this feature accidentally breaking existing web content and you want to get
> > bug reports from normal users?
> >
> > Could we mitigate risk by disabling this feature in chrome code by default
> > until you're confident in its readiness to ship?
> >
> > --BDS
> >
> >
> > On Mon, Mar 27, 2017 at 10:33 AM, Tooru Fujisawa 
> > wrote:
> >
> > > I just landed the initial implementation of Async Iteration proposal
> > > (async generator and for-await-of syntax), as non-release-only feature.
> > >
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1331092
> > >
> > > The implementation is only for the testing purpose (for finding spec bug
> > > etc), and the semantic change in the spec is highly expected.  They're
> > not
> > > yet ready for production usage, either in browser code or in testcases.
> > > Please wait for a while :)
> > >
> > > --
> > >
> > > arai
> > >
> > > ___
> > > 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
> 
> 
> 
> -- 
>shu
> 
> 
> 
> -- 
>shu

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