Building Firefox install
Hi, I've made some modifications to the Firefox source code and now I would like to build the install exe on Windows, so that i can normally install Firefox (I want to couple it with a crawler - http://crawljax.com/). However I would like that installation to be standard Firefox (and not nightly!; the crawler via selenium can establish communication with standard Firefox, even the portable one, but for some reason cannot with the Nightly version, even with the selenium supported version of Nightly). I've tried to add: ac_add_options --enable-official-branding to the .mozconfig file compiling the source code and then building the installer with mach build browser/installer/windows However, when i try to use the installer, it installs the Nightly version. How can I build a normal, standard Firefox installer for Windows, like the one distributed to standard Firefox users? Thank you, Josip ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozReview ready for general use
Is there any chance we could log in with Persona? Cheers, David On 06/11/14 05:50, Mark Côté wrote: A couple months ago I gave a sneak peak into our new repository-based code-review tool based on Review Board. I'm excited to announce that this tool, now named (descriptively but unimaginatively) MozReview, is ready for general use. In the interests of beta-testing our documentation at the same time as our code, I want to mostly confine my post to a link to our docs: http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview.html Everything you need should be in there. The only item I want to highlight here is that, yes, we know the UI is currently not great. We bolted some stuff onto the basic Review Board interface for our repository-centric work flow. We're working on integrating that into a whole new look feel that will also strip out the bits that aren't as pertinent to our approach to code review. Please bear with us! We hope that, UI warts notwithstanding, you'll still enjoy this fresh approach to code review at Mozilla. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozReview ready for general use
It looks like all reviews (and patches) are currently public. Is there some way to have them not be so, for security/confidential bugs/reviews? ~ Gijs On 06/11/2014 04:50, Mark Côté wrote: A couple months ago I gave a sneak peak into our new repository-based code-review tool based on Review Board. I'm excited to announce that this tool, now named (descriptively but unimaginatively) MozReview, is ready for general use. In the interests of beta-testing our documentation at the same time as our code, I want to mostly confine my post to a link to our docs: http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview.html Everything you need should be in there. The only item I want to highlight here is that, yes, we know the UI is currently not great. We bolted some stuff onto the basic Review Board interface for our repository-centric work flow. We're working on integrating that into a whole new look feel that will also strip out the bits that aren't as pertinent to our approach to code review. Please bear with us! We hope that, UI warts notwithstanding, you'll still enjoy this fresh approach to code review at Mozilla. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Test Informant Report - Week ending Nov 08
Test Informant report for 2014-11-08. State of test manifests at revision d380166816dd. Using revision 0b81c10a9074 as a baseline for comparisons. Showing tests enabled or disabled between 2014-11-02 and 2014-11-08. 87% of tests across all suites and configurations are enabled. Summary --- marionette- ↑8↓0 - 92% mochitest-a11y- ↑0↓0 - 99% mochitest-browser-chrome - ↑176↓144 - 94% mochitest-browser-chrome-e10s - ↑328↓14 - 43% mochitest-chrome - ↑16↓64 - 97% mochitest-plain - ↑162↓96 - 86% mochitest-plain-e10s - ↑48↓56 - 79% xpcshell - ↑68↓40 - 92% Full Report --- http://brasstacks.mozilla.com/testreports/weekly/2014-11-08.informant-report.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozReview ready for general use
Unfortunately that's very difficult given the various communication pathways between hg review repo, the Review Board API, and the BMO API, especially considering BMO's support of Persona is a bit sketchy. We'll look into it, but it's not a high priority at the moment. Mark On 2014-11-10 5:51 AM, David Rajchenbach-Teller wrote: Is there any chance we could log in with Persona? Cheers, David On 06/11/14 05:50, Mark Côté wrote: A couple months ago I gave a sneak peak into our new repository-based code-review tool based on Review Board. I'm excited to announce that this tool, now named (descriptively but unimaginatively) MozReview, is ready for general use. In the interests of beta-testing our documentation at the same time as our code, I want to mostly confine my post to a link to our docs: http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview.html Everything you need should be in there. The only item I want to highlight here is that, yes, we know the UI is currently not great. We bolted some stuff onto the basic Review Board interface for our repository-centric work flow. We're working on integrating that into a whole new look feel that will also strip out the bits that aren't as pertinent to our approach to code review. Please bear with us! We hope that, UI warts notwithstanding, you'll still enjoy this fresh approach to code review at Mozilla. Mark ___ 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: MozReview ready for general use
That is an excellent point which I forgot to call out: please do NOT try to use MozReview for confidential/security/nonpublic patches. MozReview will actually prevent you from publishing a review request linked to a nonpublic bug. Review Board does not have anything close to the fine-grained security model used by BMO; eventually we will support all our use cases, but this will require careful consideration and a lot more work in our Review Board extensions. For now, nonpublic patch should use old review system (Splinter). Apologies for the inconvenience. Mark On 2014-11-10 6:31 AM, Gijs Kruitbosch wrote: It looks like all reviews (and patches) are currently public. Is there some way to have them not be so, for security/confidential bugs/reviews? ~ Gijs On 06/11/2014 04:50, Mark Côté wrote: A couple months ago I gave a sneak peak into our new repository-based code-review tool based on Review Board. I'm excited to announce that this tool, now named (descriptively but unimaginatively) MozReview, is ready for general use. In the interests of beta-testing our documentation at the same time as our code, I want to mostly confine my post to a link to our docs: http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview.html Everything you need should be in there. The only item I want to highlight here is that, yes, we know the UI is currently not great. We bolted some stuff onto the basic Review Board interface for our repository-centric work flow. We're working on integrating that into a whole new look feel that will also strip out the bits that aren't as pertinent to our approach to code review. Please bear with us! We hope that, UI warts notwithstanding, you'll still enjoy this fresh approach to code review at Mozilla. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozReview ready for general use
This is awesome, everything seems to be working great so far! While adapting to mozreview, I also took the opportunity to use hg bookmarks instead of mq and to switch to a unified repo (m-c, m-i, m-a etc, all in the same local clone). If anyone else is thinking about making a similar switch and is wondering how all the various pieces fit together, I blogged about the steps needed: http://ahal.ca/blog/2014/new-mercurial-workflow/ On 05/11/14 11:50 PM, Mark Côté wrote: A couple months ago I gave a sneak peak into our new repository-based code-review tool based on Review Board. I'm excited to announce that this tool, now named (descriptively but unimaginatively) MozReview, is ready for general use. In the interests of beta-testing our documentation at the same time as our code, I want to mostly confine my post to a link to our docs: http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview.html Everything you need should be in there. The only item I want to highlight here is that, yes, we know the UI is currently not great. We bolted some stuff onto the basic Review Board interface for our repository-centric work flow. We're working on integrating that into a whole new look feel that will also strip out the bits that aren't as pertinent to our approach to code review. Please bear with us! We hope that, UI warts notwithstanding, you'll still enjoy this fresh approach to code review at Mozilla. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Session Restore (sessionstore)
Experience shows that many users really, really like all the features of Session Restore and that we can't easily drop any. However, if you have references to websites that you haven't visited in years, that's not normal. Either these websites are still opened in some tab, or there is a bug in Session Restore. Could you double-check that you really haven't visited them in years? Cheers, David On 06/11/14 08:07, jlouz...@gmail.com wrote: Personally I feel that ss.js might be suffering from a bit of feature bloat. As such if someone really does have 1000 tabs open, I would think that the content of those tabs were more important than the histories of each. I found this group because I recently lost a whole bunch of open-tabs and then I read up and found out about sessionstore.js but when I tried to manually open it it was complete jibberish; some websites were mentioned that I haven't visited in years probably! If there's a chance that this feature be redesigned, it might be easier to just provide basic tab-recovery initially and then branch out into other essentials. Or maybe to offer those things as separate add-ons. Just my personal opinion. Losing open tabs is too painful sometimes. :/ -Joel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Where does the FF addon manager get the change log from?
Hello, this is a question about the Firefox addon manager and where the developer of an addon has to put the change log in order to be displayed after an update of that addon inside the addon manager. It is unclear how the process of the addon manager being able to retrieve the change log of an updated addon works. I got pointed to this list by a Mozilla person. I am not subscribed to this, but I'll be able to check the archives. I asked to include the change log so the addon manager would display it. [1] Now the question is what a developer has to do in order to make this work. Thank you in advance for explaining it or pointing to exiting documentation, I have not found. Kind Regards, Sebastian [1]https://github.com/futpib/policeman/issues/35 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Assertion failure on Ubuntu
I recently build firefox on Ubuntu 14.04 on vmware and when i tried running test , i got this :http://pastebin.mozilla.org/7217190 In my .mozconfig file, i have only two options: ac_add_options --enable-debug ac_add_options --disable-optimize ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: About the bitfield requirement for portibility
On Thu, Nov 06, 2014 at 01:36:05PM -0800, Chris Peterson wrote: On 11/6/14 10:22 AM, Jason Orendorff wrote: I guess I was a little irked that people are still tripping over this ancient document (didn't we delete that?), because I just took the time to clobber most of it and update what was left. https://developer.mozilla.org/en-US/docs/Mozilla/Cpp_portability_guide Regarding Don't use static constructors, clang has an optional -Wglobal-constructors warning for global and static C++ objects. Firefox has 539 instances. Last time I looked we had only a hundred static ctors or so. Global objects with ctors are fine if the class has a trivial dtor, andthe constructor is marked as constexpr (at least roughly). Trev An unofficial list of clang's (mysteriously undocumented) warnings: http://fuckingclangwarnings.com/ chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Assertion failure on Ubuntu
This is https://bugzilla.mozilla.org/show_bug.cgi?id=1053508 . If you can help glandium debug/reproduce it, that would be awesome. On Sun, Nov 9, 2014 at 6:40 PM, Harsh Vardhan harshv...@gmail.com wrote: I recently build firefox on Ubuntu 14.04 on vmware and when i tried running test , i got this :http://pastebin.mozilla.org/7217190 In my .mozconfig file, i have only two options: ac_add_options --enable-debug ac_add_options --disable-optimize ___ 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: Assertion failure on Ubuntu
Yes, I had the same problem in an ubuntu VM. I debugged it with glandium for a while, but was very busy at the time and eventually cut my losses and switched tasks. If Harsh has the cycles to play debug-server for glandium, hopefully they can get to the bottom of this. On Mon, Nov 10, 2014 at 8:45 AM, Josh Matthews j...@joshmatthews.net wrote: Harsh said in #introduction that it's the first time he's tried to run mochitests, and this is a relatively new environment (less than a month, maybe?). On 2014-11-09 9:40 PM, Harsh Vardhan wrote: I recently build firefox on Ubuntu 14.04 on vmware and when i tried running test , i got this :http://pastebin.mozilla.org/7217190 In my .mozconfig file, i have only two options: ac_add_options --enable-debug ac_add_options --disable-optimize ___ 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: MozReview ready for general use
On 11/9/14 8:29 PM, Boris Zbarsky wrote: On 11/9/14, 11:10 PM, Gregory Szorc wrote: We currently only attempt to map each review/commit series to a single bug. This is definitely a problem; it serializes workflow such that you have to get review on bug 1 and land it before you can even request review on bug 2 that depends on bug 1, no? This is a pretty common situation, unfortunately. I fully understand that this is a common problem. I think if we land support for specifying the base revision to review (currently it takes all non-public changesets up to the revision you specify or . if none), that will be a sufficient stop-gap until proper multi-bug support is implemented. We will support multiple bugs eventually. Do we have any estimate on timing? No. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozReview ready for general use
On 11/10/14, 12:14 PM, Gregory Szorc wrote: I think if we land support for specifying the base revision to review (currently it takes all non-public changesets up to the revision you specify or . if none), that will be a sufficient stop-gap until proper multi-bug support is implemented. Yes, agreed. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Building Firefox install
On 11/10/2014 01:44 AM, Josip Maras wrote: How can I build a normal, standard Firefox installer for Windows, like the one distributed to standard Firefox users? I don't know the answer to your specific question (I've never personally had to build the installer), but just as a heads-up: you can't legally *distribute* a modified Firefox build, using the official branding/trademarks, unless you've gotten explicit permission. See Modifications section here: https://www.mozilla.org/en-US/foundation/trademarks/policy/ Hopefully you already know this your build is just for personal use not for distribution to others. :) Anyway, good luck with your build issue. Thanks, ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Building Firefox install
On Monday, November 10, 2014 8:36:36 PM UTC+1, Daniel Holbert wrote: On 11/10/2014 01:44 AM, Josip Maras wrote: How can I build a normal, standard Firefox installer for Windows, like the one distributed to standard Firefox users? I don't know the answer to your specific question (I've never personally had to build the installer), but just as a heads-up: you can't legally *distribute* a modified Firefox build, using the official branding/trademarks, unless you've gotten explicit permission. See Modifications section here: https://www.mozilla.org/en-US/foundation/trademarks/policy/ Hopefully you already know this your build is just for personal use not for distribution to others. :) Anyway, good luck with your build issue. Thanks, ~Daniel Hi Daniel, Yes I know this, and it is purely for my own use - i plan to install this on a couple of computers and run some experiments. Thanks, Josip ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: power use on Yosemite
On Nov 3, 2014, at 1:44 PM, rviti...@mozilla.com wrote: In particular Facebook, which practically appears in any top 10 list, had (has?) a serious power bug that caused FF to render a hidden spinning wheel. Because of this single bug any power benchmark performed by the press, which was likely going to be based on the top N most visited sites on the web, was likely going to be skewed significantly to our loss. This is bug 962594; I pushed in a fix last week. Debugging the problem revealed that some simple architectural changes could let us solve not only this bug but the entire category of related bugs (there are more; see for example bug 987212) in a very clean way. It will take some time to get the pieces into place, but we should be much more efficient in our handling of non-visible animated images soon. Thanks for identifying these problems and pushing to get them fixed, Roberto! - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: You can now use Maybe with the Auto helpers for Mutex and Monitor
In bug 1091921, we got support for using Maybe with the Auto helpers for Mutex
and Monitor - things like MutexAutoLock and MonitorAutoEnter. This supports a
pattern for optionally acquiring a RAII resource that I first saw used in the
JavaScript engine, and which I’ve found very useful since. For anyone who
hasn’t seen it, the basic pattern looks like this:
MaybeExpensiveRAIIResource resource;
if (resourceIsNeeded) {
resource.emplace();
}
This constructs an ExpensiveRAIIResource on the stack only if
|resourceIsNeeded| is true.
So bug 1091921 lets us use this pattern with Mutexes and Monitors. I’m sure
people will find lots of situations where this is useful, and indeed it’s
already being used in some places.
Any time you have parallelism, though, you need to exercise caution. I
encourage anyone who wants to use this to start by adding assertions to their
code like Mutex’s |AssertCurrentThreadOwns| or Monitor’s
|AssertCurrentThreadIn| anywhere they have methods that expect another method
to do their synchronization for them. That’s good practice in any case, and
will help ensure that you don’t make a mistake when using Maybe in this way.
Enjoy!
- Seth
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: You can now use Maybe with the Auto helpers for Mutex and Monitor
On Mon, Nov 10, 2014 at 1:59 PM, Seth Fowler s...@mozilla.com wrote:
In bug 1091921, we got support for using Maybe with the Auto helpers for
Mutex and Monitor - things like MutexAutoLock and MonitorAutoEnter. This
supports a pattern for optionally acquiring a RAII resource that I first saw
used in the JavaScript engine, and which I’ve found very useful since. For
anyone who hasn’t seen it, the basic pattern looks like this:
MaybeExpensiveRAIIResource resource;
if (resourceIsNeeded) {
resource.emplace();
}
This constructs an ExpensiveRAIIResource on the stack only if
|resourceIsNeeded| is true.
So bug 1091921 lets us use this pattern with Mutexes and Monitors. I’m sure
people will find lots of situations where this is useful, and indeed it’s
already being used in some places.
Any time you have parallelism, though, you need to exercise caution. I
encourage anyone who wants to use this to start by adding assertions to their
code like Mutex’s |AssertCurrentThreadOwns| or Monitor’s
|AssertCurrentThreadIn| anywhere they have methods that expect another method
to do their synchronization for them. That’s good practice in any case, and
will help ensure that you don’t make a mistake when using Maybe in this way.
Enjoy!
- Seth
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Since we're on the subject, I'll point out that
AssertCurrentThreadOwns is debug only (looking at you b2g, with your
almost complete lack of debug testing) and AssertNotCurrentThreadOwns
is unimplemented and for documentation purposes only.
- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
RE: Building Firefox install
Since you are using Nightly it defaults to Nightly. I'm not positive this covers everything but to make Nightly use a different name you will need to set MOZ_APP_NAME and MOZ_APP_DISPLAYNAME to the names you want and set --with-branding=%RELATIVE_PATH_TO_THAT_DIR% and point it to the branding directory under browser/branding/ that you want when building. Robert On Monday, November 10, 2014 8:36:36 PM UTC+1, Daniel Holbert wrote: On 11/10/2014 01:44 AM, Josip Maras wrote: How can I build a normal, standard Firefox installer for Windows, like the one distributed to standard Firefox users? I don't know the answer to your specific question (I've never personally had to build the installer), but just as a heads-up: you can't legally *distribute* a modified Firefox build, using the official branding/trademarks, unless you've gotten explicit permission. See Modifications section here: https://www.mozilla.org/en-US/foundation/trademarks/policy/ Hopefully you already know this your build is just for personal use not for distribution to others. :) Anyway, good luck with your build issue. Thanks, ~Daniel Hi Daniel, Yes I know this, and it is purely for my own use - i plan to install this on a couple of computers and run some experiments. Thanks, Josip ___ 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
MemShrink Meeting - Tuesday, 11 Nov 2014 at 2:00pm PST
Note: new meeting time! The next Memshrink meeting is is brought to you by the replace_malloc tool to capture and reproduce Firefox's memory allocations: https://bugzilla.mozilla.org/show_bug.cgi?id=1083686 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, 11 November, 2:00 PM PST * http://arewemeetingyet.com/Los%20Angeles/2014-11-11/14:00/MemShrink%20Meeting * Vidyo: Memshrink * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 98802 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: the 'box-decoration-break' CSS property
On 11/09/2014 06:28 PM, sime.vi...@gmail.com wrote: On Friday, July 11, 2014 7:38:39 PM UTC+2, Mats Palmgren wrote: IE10 has -ms-box-decoration-break I've tested[1] this property in IE11 with the values slice and clone. IE does not seem to support it. (I've also checked in older versions via Document Mode in F12 tools.) [1]: http://jsbin.com/zusuwo/1/edit?css,output Right, it appears I was mistaken. The rendering in IE when using a large 'border-radius' is quite broken and it looks a bit like 'clone' (as your example shows) so I guess that's what lead me to believe it was supported. I've corrected the MDN page, thanks! /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s is now enabled by default for Nightly!
e10s also broke playback of audio streams in MP4 files... bug 1096717. Chris P. On 11/7/2014 1:27 PM, Chris Peterson wrote: The patch is on mozilla-inbound and ought to hit mozilla-central in time for tomorrow's Nightly build. \o/ https://hg.mozilla.org/integration/mozilla-inbound/rev/a75897e664dd e10s will not ride the trains to Aurora 36. Talos and unit tests will continue to run for e10s and non-e10s until e10s hits the Release channel. Some known problems: * IME and a11y will disable e10s until support is completed * Some performance problems with Adblock Plus * Bug 947030 - Ghostery add-on does not block trackers * Bug 972507 - BugzillaJS add-on does not work [1] * Bug 1008768 - LastPass add-on does not fill in form fields * Bug 1014986 - HTTPS Everywhere add-on breaks HTTP redirects * Bug 1042680 - Tree Style Tabs add-on does not work * Bug 1042195 - 1Password add-on does not work * Bug 1058542 - NoScript add-on does not work * Bug 1093161 - Searching from address bar does not work the first time If you have any questions, drop by #e10s on IRC. If you file new bugs related to e10s, please include the word e10s in the summary so the e10s team's triage queries will find your bug. chris [1] btw, BugzillaJS is seeking a new maintainer: https://www.yammer.com/mozillians/#/threads/show?threadId=454089406 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
