[Firefox Desktop] Issues found: February 20th to February 24th

[Cornel Ionce]

Hi everyone,


Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *February 20 - February 24* (week 8).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1341638  	Unable to play vtt video by 
clicking inside the video area when close caption menu is active

Toolkit Video/Audio Controls
NO  NOBODY
1341691  	Tapping twice on the  
combobox doesn't close it on touch devices

Core
Panning and Zooming
YES Kartikaya Gupta 
1342056 
	[Non-e10s] Grid highlighter changes position after page refresh when 
page with grid is in iframe

Firefox
Developer Tools: Inspector  NO  NOBODY
1342476 
	The insecure password support page can't be accessed using only the 
keyboard

Firefox
Security
TBD NOBODY
1342051 
	Grid highlighter can no longer be activated after Inspector close and 
page refresh 	Firefox

Developer Tools: Inspector
NO  NOBODY

*
AURORA CHANNEL*
none

*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1341227  	[Mac] Hover Feedback not aligned 
with zoom buttons separator 	Firefox 	Theme 	YES 
 
	NOBODY

1342026
 	Grid highlighter disappears changing the 
height of developer toggle tools inside Fx

Firefox
Developer Tools: Inspector
	YES 
 
	NOBODY




*
ESR CHANNEL*
none


Regards,
Cornel Ionce
Team Lead
Softvision

The content of this communication is classified as Softvision 
Confidential and Proprietary Information.


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

Re: Doxygen output?

[Andrew Sutherland]

On Tue, Feb 21, 2017, at 04:42 PM, Andrew Sutherland wrote:
> A sketch first steps implementation would be:

I took a shot at this.  The pull request with details is at
https://github.com/bill-mccloskey/searchfox/pull/11 and hopefully
self-explanatory screenshots are here:
https://clicky.visophyte.org/examples/searchfox/20170227/static-field-decl-comments.png
https://clicky.visophyte.org/examples/searchfox/20170227/static-field-uses.png
https://clicky.visophyte.org/examples/searchfox/20170227/method-def-decl-comment.png

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

PSA: ESLint no-undef rule now enabled for all of toolkit/

[Mark Banner]

The "no undefined" eslint rule has now been enabled for all of toolkit/ 
- this landed last Friday.


The devmo  page has 
been updated with further information about the rule and some of the 
flags that are occasionally necessary.


Enabling it for all of browser/ will happen in the next few weeks.

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

Re: Editing vendored crates

[Henri Sivonen]

On Mon, Feb 27, 2017 at 12:10 AM, Bobby Holley  wrote:
> Can you elaborate on what goes wrong here? This worked for ted's experiment
> mentioned upthread, and for me on at least one occasion in
> https://hg.mozilla.org/try/rev/18dc070e0308 (permalink:
> https://pastebin.mozilla.org/8980438 )
>
> You'll need to |cargo update| after adding the replace in Cargo.toml to
> update Cargo.lock.

Thanks. I failed to do that yesterday.

When I do that, Cargo complains about not finding the
encoding-index-foo crates in subdirectories of encoding. Replacement
in gkrust's Cargo.toml doesn't work. So then I go and edit encoding's
Cargo.toml to point it to the right place. Then Cargo complains about
those crates not finding encoding_index_tests. So then I edit their
Cargo.tomls to point to the test crate.

Then cargo update passes.

But then I do ./mach build and Cargo complains about the checksums not
matching because I edited the Cargo.tomls under the crates that I
thought I was changing from "locally-stored crates.io crate" status to
"local replacement" status.

The I remove the checksum file.

The cargo complains about not finding the checksum file.

I find this level of difficulty (self-inflicted quasi-Tivoization
practically) an unreasonable impediment to practicing trivial Software
Freedom with respect to the vendored crates.

> This is basically the right way to do it, rather than editing the checksums. 
> [replace] tells the Cargo machinery that the vendored code is its own 
> snowflake, rather than just a cache of what's on crates.io. Doing otherwise 
> breaks cargo invariants.

What are the invariants? Why do we need the invariants, when can do
without impediments like these for e.g. the vendored copy of ICU?

What badness would arise from patching Cargo to ignore the
.cargo-checksum.json files?

On Mon, Feb 27, 2017 at 1:23 AM, Xidorn Quan  wrote:
> This workflow should really be automated via a mach command. Filed bug
> 1342815 [1] for that.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1342815

Thank you. I think it should be possible to stick a diagnostic
println!() or panic!() in the vendored code with zero or minimal
ceremony.

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

Re: Please consider whether new APIs/functionality should be disabled by default in sandboxed iframes

[David Bruant]

Hi Boris,

Did a particular feature triggered your message?

Would it make sense to add the question to the "Intent to Implement" email 
template?
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement

"Intent to" emails seem like a good time to ask this questions/raise:
* the feature is not implemented yet
* other browsers vendors are reading the "intent to" emails, so there is an 
opportunity for this question to be fixed in an interoperable manner

David


Le mercredi 11 janvier 2017 18:34:56 UTC+1, Boris Zbarsky a écrit :
> When adding a new API or CSS/HTML feature, please consider whether it 
> should be disabled by default in sandboxed iframes, with a sandbox token 
> to enable.
> 
> Note that this is impossible to do post-facto to already-shipped APIs, 
> due to breaking compat.  But for an API just being added, this is a 
> reasonable option and should be strongly considered.
> 
> -Boris

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

Re: Should cheddar-generated headers be checked in?

[Henri Sivonen]

On Mon, Feb 27, 2017 at 1:40 AM, Xidorn Quan  wrote:
>> When doing a parallel build, I see an interleave of C++ and Rust build
>> system output. What guarantees that a build.rs that exports headers
>> runs before the C++ compiler wants to see the headers?
>
> Oh, it's about C++ header generated from Rust?

Yes. cheddar, not bindgen.

> I don't think it is
> possible given the current architecture.
...
> So if it is Rust library exposing C API, it is probably responsibility
> of the Rust library to also provide a C header for other code to use.

I take it that I should check in the header, then.

Is there some way to disable build.rs for a vendored crate (without
making cargo unhappy about the hashes)? (If the header is checked in,
compiling cheddar in order to generate it at build time is useless.)

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

Re: Please consider whether new APIs/functionality should be disabled by default in sandboxed iframes

[Boris Zbarsky]

On 2/27/17 7:07 AM, David Bruant wrote:

Did a particular feature triggered your message?


No, it was just something I had been thinking about for a bit.


Would it make sense to add the question to the "Intent to Implement" email 
template?
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement


That's probably a good idea.  I added it there:

   Is this feature enabled by default in sandboxed iframes? If not, is 
there a proposed sandbox flag to enable it? If allowed, does it preserve 
the current invariants in terms of what sandboxed iframes can do?


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

Re: Intent to implement: Frames timing functions

[Boris Chiou]

OK, sure. I will add a pref to protect it. Thanks for suggestion.

On Sat, Feb 25, 2017 at 12:09 AM,  wrote:

> On Thursday, February 23, 2017 at 9:09:58 AM UTC-6, Boris Chiou wrote:
> > *Preference behind which this will be implemented*: I'm not sure. I think
> > we don't need it because it is just a variant of the step timing
> function,
> > and so it is safe to turn it on. If there is any other concerns, I can
> add
> > a preference for this.
>
> Given our (and all browsers') painful history with people finding novel
> ways to bypass security by abusing any and all timers we expose, I would
> feel much better if this had a pref.
>
> -tom
> ___
> 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: Should cheddar-generated headers be checked in?

[Henri Sivonen]

On Mon, Feb 27, 2017 at 2:38 PM, Henri Sivonen  wrote:
> Is there some way to disable build.rs for a vendored crate (without
> making cargo unhappy about the hashes)? (If the header is checked in,
> compiling cheddar in order to generate it at build time is useless.)

This seems not only relevant for build time but relevant to what
dependencies we vendor.

Right now, running ./mach vendor rust with gkrust depending on
https://crates.io/crates/encoding_c pulls in the dependencies for
cheddar, which we apparently don't already have in the tree.

Maybe having the header generation as part of build.rs is more trouble
than it's worth in the first place...

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

Re: Visual Studio Code recommended extensions

[Marco Bonardo]

On Mon, Feb 27, 2017 at 5:12 PM, Dan Mosedale  wrote:

> It sounds like you find it better than Atom.  If that's true, any chance
> you could elaborate on what you find particularly nicer and/or what's
> missing?
>

Personally, I find it faster on common operations (starting up, opening
documents) and has some extensions covering my needs that are still
pending unfixed bugs in Atom (like removing trailing whitespaces only on
lines that I touch, https://github.com/atom/whitespace/issues/8).
I didn't test the most recent Atom version, but in general VS Code feels
lighter than the last time I tried Atom.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Editing vendored crates

[Ralph Giles]

On Mon, Feb 27, 2017 at 4:03 AM, Henri Sivonen  wrote:

> I find this level of difficulty (self-inflicted quasi-Tivoization
> practically) an unreasonable impediment to practicing trivial Software
> Freedom with respect to the vendored crates.

I agree we need to fix the ergonomics here, but I don't think you
should be so hard on cargo. The hash checking is designed to make
builds more reproducible, so that unless we make an explicit diversion
we know we're building with the same source as every other use of that
same package version. This has benefits for security, debugging, and
change control.

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

Re: Editing vendored crates

[Henri Sivonen]

On Mon, Feb 27, 2017 at 7:04 PM, Ralph Giles  wrote:
> On Mon, Feb 27, 2017 at 4:03 AM, Henri Sivonen  wrote:
>
>> I find this level of difficulty (self-inflicted quasi-Tivoization
>> practically) an unreasonable impediment to practicing trivial Software
>> Freedom with respect to the vendored crates.
>
> I agree we need to fix the ergonomics here, but I don't think you
> should be so hard on cargo.

Sorry about the tone. I'm rather frustrated at how hard it is to do
something that should be absolutely trivial (adding a local diagnostic
panic!()/println!()).

> The hash checking is designed to make
> builds more reproducible, so that unless we make an explicit diversion
> we know we're building with the same source as every other use of that
> same package version. This has benefits for security, debugging, and
> change control.

We don't seem to need such change control beyond hg logs for e.g. the
in-tree ICU or Skia, though.

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

Re: Editing vendored crates

[Ted Mielczarek]

On Mon, Feb 27, 2017, at 12:32 PM, Henri Sivonen wrote:
> On Mon, Feb 27, 2017 at 7:04 PM, Ralph Giles  wrote:
> > On Mon, Feb 27, 2017 at 4:03 AM, Henri Sivonen  wrote:
> >
> >> I find this level of difficulty (self-inflicted quasi-Tivoization
> >> practically) an unreasonable impediment to practicing trivial Software
> >> Freedom with respect to the vendored crates.
> >
> > I agree we need to fix the ergonomics here, but I don't think you
> > should be so hard on cargo.
> 
> Sorry about the tone. I'm rather frustrated at how hard it is to do
> something that should be absolutely trivial (adding a local diagnostic
> panic!()/println!()).
> 
> > The hash checking is designed to make
> > builds more reproducible, so that unless we make an explicit diversion
> > we know we're building with the same source as every other use of that
> > same package version. This has benefits for security, debugging, and
> > change control.
> 
> We don't seem to need such change control beyond hg logs for e.g. the
> in-tree ICU or Skia, though.

As someone who has maintained a vendored upstream C++ project (Breakpad)
for a decade, I can say that this causes us headaches *all the time*. We
are constantly landing local changes to vendored projects and not
keeping track of them and then either losing patches or dealing with
conflicts or breakage when we update from upstream.

I'm sorry this is causing you pain, and we should figure out a way to
make it less painful, but note that the intention is that things in
`third_party/rust` should be actual third-party code, not things under
active development by Mozilla. We don't currently have a great middle
ground between "mozilla-central is the repository of record for this
crate" and "this crate is vendored from crates.io". We're finding our
way there with Servo, so we might have a better story for things like
encoding-rs when we get that working well. I understand that there are
lots of benefits to developing a crate in a standalone GitHub
repository, and you're certainly not the only one who wants to do that,
but it does make the integration story harder. It's very hard to support
code that has its repository of record somewhere other than
mozilla-central, but also have a simple workflow for making changes to
that code in mozilla-central along with other code.

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

Re: Editing vendored crates

[Henri Sivonen]

On Mon, Feb 27, 2017 at 7:47 PM, Ted Mielczarek  wrote:
> On Mon, Feb 27, 2017, at 12:32 PM, Henri Sivonen wrote:
>> We don't seem to need such change control beyond hg logs for e.g. the
>> in-tree ICU or Skia, though.
>
> As someone who has maintained a vendored upstream C++ project (Breakpad)
> for a decade, I can say that this causes us headaches *all the time*.

OK.

> I'm sorry this is causing you pain, and we should figure out a way to
> make it less painful, but note that the intention is that things in
> `third_party/rust` should be actual third-party code, not things under
> active development by Mozilla. We don't currently have a great middle
> ground between "mozilla-central is the repository of record for this
> crate" and "this crate is vendored from crates.io". We're finding our
> way there with Servo, so we might have a better story for things like
> encoding-rs when we get that working well.

Note that my problem at hand isn't with encoding_rs but with the
currently-vendored rust-encoding. That is, I indeed would like to add
a diagnostic panic!()/println!() to genuinely third-party code--not to
code I've written.

That is, I'd like to experimentally understand what, if anything,
rust-encoding is currently used for. (My best current hypothesis from
reading things on SearchFox is that it's used in order to be able to
compile one Option that's always None in Gecko.)

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

Re: Editing vendored crates

[Bobby Holley]

On Mon, Feb 27, 2017 at 9:56 AM, Henri Sivonen  wrote:

> On Mon, Feb 27, 2017 at 7:47 PM, Ted Mielczarek 
> wrote:
> > On Mon, Feb 27, 2017, at 12:32 PM, Henri Sivonen wrote:
> >> We don't seem to need such change control beyond hg logs for e.g. the
> >> in-tree ICU or Skia, though.
> >
> > As someone who has maintained a vendored upstream C++ project (Breakpad)
> > for a decade, I can say that this causes us headaches *all the time*.
>
> OK.
>
> > I'm sorry this is causing you pain, and we should figure out a way to
> > make it less painful, but note that the intention is that things in
> > `third_party/rust` should be actual third-party code, not things under
> > active development by Mozilla. We don't currently have a great middle
> > ground between "mozilla-central is the repository of record for this
> > crate" and "this crate is vendored from crates.io". We're finding our
> > way there with Servo, so we might have a better story for things like
> > encoding-rs when we get that working well.
>
> Note that my problem at hand isn't with encoding_rs but with the
> currently-vendored rust-encoding. That is, I indeed would like to add
> a diagnostic panic!()/println!() to genuinely third-party code--not to
> code I've written.
>

To be clear, I totally agree that local debugging-oriented edits to
vendored crates should be painless. A 1-line mach command to add a cargo
[replace] and update Cargo.lock (with a helpful message if somebody forgets
to do that) seems like the right way to do that.

>
> That is, I'd like to experimentally understand what, if anything,
> rust-encoding is currently used for. (My best current hypothesis from
> reading things on SearchFox is that it's used in order to be able to
> compile one Option that's always None in Gecko.)
>

FWIW, |cargo tree| is a very helpful tool to figure out who's pulling in a
crate.


>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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: Editing vendored crates

[Henri Sivonen]

On Mon, Feb 27, 2017 at 8:00 PM, Bobby Holley  wrote:
> FWIW, |cargo tree| is a very helpful tool to figure out who's pulling in a
> crate.

Thanks, but what I'm trying to figure out isn't whose pulling it in
(the style crate is) but whether it is actually used beyond an
always-None Option in a way that would result in the data
tables actually getting included in the build as oppose to (hopefully)
getting discarded by LTO.

(Motivation: If we are taking on the data tables, I want to argue that
we should include encoding_rs instead even before the "replace uconv
with encoding_rs" step is done.)

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

Re: Editing vendored crates

[Simon Sapin]

On 27/02/17 19:30, Henri Sivonen wrote:

On Mon, Feb 27, 2017 at 8:00 PM, Bobby Holley  wrote:

FWIW, |cargo tree| is a very helpful tool to figure out who's pulling in a
crate.


Thanks, but what I'm trying to figure out isn't whose pulling it in
(the style crate is) but whether it is actually used beyond an
always-None Option in a way that would result in the data
tables actually getting included in the build as oppose to (hopefully)
getting discarded by LTO.

(Motivation: If we are taking on the data tables, I want to argue that
we should include encoding_rs instead even before the "replace uconv
with encoding_rs" step is done.)


As an aside, I have a plan to remove rust-encoding entirely from Servo 
(including Stylo) and use encoding_rs instead. But doing this the way I 
want to has a number of prerequisites, and I’d prefer to switch 
everything at once to avoid having both in the build. At the moment I’m 
prioritizing other Stylo-related work, but I’m confident it’ll happen 
before we start shipping Stylo.


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

Re: Editing vendored crates

[Henri Sivonen]

On Mon, Feb 27, 2017 at 8:47 PM, Simon Sapin  wrote:
> As an aside, I have a plan to remove rust-encoding entirely from Servo
> (including Stylo) and use encoding_rs instead. But doing this the way I want
> to has a number of prerequisites, and I’d prefer to switch everything at
> once to avoid having both in the build. At the moment I’m prioritizing other
> Stylo-related work, but I’m confident it’ll happen before we start shipping
> Stylo.

Nice! Works for me. :-)

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

Re: Should cheddar-generated headers be checked in?

[Henri Sivonen]

On Mon, Feb 27, 2017 at 5:57 PM, Henri Sivonen  wrote:
> Maybe having the header generation as part of build.rs is more trouble
> than it's worth in the first place...

Now that the build.rs in commented out in the crates.io crate and the
generated header is shipped in the crates.io crate:
Considering that editing the vendored crates is not allowed, so I
can't put moz.build files on the path to the headers, what's the
appropriate way to make the m-c build system pick up headers from
third_party/rust/encoding_c/include?

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

Re: Should cheddar-generated headers be checked in?

[Simon Sapin]

On 27/02/17 19:57, Henri Sivonen wrote:

On Mon, Feb 27, 2017 at 5:57 PM, Henri Sivonen  wrote:

Maybe having the header generation as part of build.rs is more trouble
than it's worth in the first place...


Now that the build.rs in commented out in the crates.io crate and the
generated header is shipped in the crates.io crate:
Considering that editing the vendored crates is not allowed, so I
can't put moz.build files on the path to the headers, what's the
appropriate way to make the m-c build system pick up headers from
third_party/rust/encoding_c/include?


I don’t know about the build system picking up part. For the restriction 
on editing vendored code, one way to work around it with cooperation 
from upstream is to use an optional cargo "feature":


http://doc.crates.io/manifest.html#the-features-section

The #[cfg(feature = "foo")] attribute and cfg!(feature = "foo") macro 
are also available in build scripts.


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

Re: Should cheddar-generated headers be checked in?

[Kartikaya Gupta]

On Mon, Feb 27, 2017 at 1:57 PM, Henri Sivonen  wrote:
> Now that the build.rs in commented out in the crates.io crate and the
> generated header is shipped in the crates.io crate:
> Considering that editing the vendored crates is not allowed, so I
> can't put moz.build files on the path to the headers, what's the
> appropriate way to make the m-c build system pick up headers from
> third_party/rust/encoding_c/include?
>

I haven't tried this myself, but you should be able to reference the
include from any moz.build file. e.g.

# in foo/bar/moz.build
EXPORTS += [
  ...
  "../../third_party/rust/encoding_c/include/MyHeader.h"
 ...
]

Does that not work?

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

Re: Embeddable Browser

[Myk Melez]

Rodolpho Porto 
2017 February 23 at 10:44

Hello Friend,

its a Java SWT application using XulRunner to create the Browser 
object, setting the xulrunner properties (i.e. 
org.eclipse.swt.browser.XulRunnerPath), and using a few browser 
configurations like TLS 1.2 only and others configurations for security.
I'm unfamiliar with this usage of XULRunner, so unfortunately I don't 
know of a suitable alternative.


Eclipse's bug database is tracking plans to remove XULRunner support 
from SWT on Mac OS 
, and XULRunner no 
longer works with GTK3 
, including on 
Windows . However, 
none of those bugs suggest an alternative.


You might try asking in a forum for SWT, like the Eclipse forums 
. Also see the my2iu/eclipse.swt.mozilla 
project, although it appears to be abandonware.


If you find a solution, please let us know!

Regards,
-myk

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