Re: Intent to implement: ScrollTimeline
Is it possible to use this, or is there a similar proposal, for linking animation timeline to other user-controlled means of interacting with the UI? I'm thinking primarily about things like: - drag&drop - the percentage of the distance between the source and target linked to the animation timeline - touch events - unfold or move an element with a thumb on mobile triggers an animation linked to the percentage of the distance between folded/unfolded. Thanks, zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Pulsebot in #developers
+1 The only thing I'd like to see from pulsebot on developers is: "26 commits have been merged from autoland into mozilla-central. List: http://..."; zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Building mozilla-central with clang + icecream
On Tuesday, November 7, 2017 at 2:54:45 AM UTC-8, pa...@paul.cx wrote:
> I'm using this setup daily (with clang trunk from some weeks ago, not
> 5.0, but it's the same really), here is my mozconfig:
>
> ```
> export CC="icecc clang"
> export CXX="icecc clang++"
> mk_add_options MOZ_MAKE_FLAGS="-j100" # adjust, this is good for the
> paris office
> mk_add_options 'export RUSTC_WRAPPER=sccache'
> mk_add_options 'export CARGO_INCREMENTAL=1'
> ```
>
> Cheers,
> Paul.
Yeah, tried the same thing and got:
```
0:02.49 checking yasm version... 1.3.0
0:02.50 checking the target C compiler version... 5.0.0
0:12.70 checking the target C compiler works... no
0:12.70 DEBUG: Creating `/tmp/conftest.E5oBtT.c` with content:
0:12.70 DEBUG: |
0:12.70 DEBUG: | int
0:12.70 DEBUG: | main(void)
0:12.70 DEBUG: | {
0:12.70 DEBUG: |
0:12.70 DEBUG: | ;
0:12.70 DEBUG: | return 0;
0:12.70 DEBUG: | }
0:12.70 DEBUG: Executing: `/usr/bin/ccache icecc /usr/bin/clang -std=gnu99 -c
/tmp/conftest.E5oBtT.c`
0:12.70 DEBUG: The command returned non-zero exit status 127.
0:12.70 DEBUG: Its error output was:
0:12.70 DEBUG: | usr/bin/clang: error while loading shared libraries:
libLLVM-5.0.so: cannot open shared object file: No such file or directory
0:12.70 DEBUG: | ICECC[8354] 18:03:45: Compiled on 10.251.25.45
0:12.70 ERROR: Failed compiling a simple C source with the target C compiler
0:12.74 *** Fix above errors and then restart with\
0:12.74"/usr/bin/make -f client.mk build"
```
Maybe it's just the SF Office icecream instance?
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Building mozilla-central with clang + icecream
Unfortunately, that still doesn't make it fly.
My mozconfig:
```
▶ cat .mozconfig
mk_add_options MOZ_MAKE_FLAGS="-j$(icecc-jobs)"
mk_add_options 'export CCACHE_PREFIX=icecc'
mk_add_options "export RUSTC_WRAPPER=sccache"
mk_add_options 'export CARGO_INCREMENTAL=1'
mk_add_options 'export
ICECC_VERSION="/home/zbraniecki/projects/mozilla-unified/380221610b59b33bb654b45d4fedb5ed.tar.gz"'
export CC="clang"
export CXX="clang++"
ac_add_options --with-ccache
ac_add_options --enable-optimize="-g -Og"
ac_add_options --enable-debug-symbols
ac_add_options --enable-debug
```
error log:
```
0:11.54 checking whether /usr/bin/ccache /usr/bin/g++ -std=gnu++11 accepts
-g... (cached) yes
0:11.55 checking for ranlib... (cached) ranlib
0:11.55 checking for as... (cached) /usr/bin/as
0:11.55 checking for ar... (cached) ar
0:11.55 checking for strip... (cached) strip
0:11.55 checking for windres... no
0:11.55 checking for otool... no
0:11.57 checking for X... (cached) libraries /usr/lib64, headers
0:11.57 checking for dnet_ntoa in -ldnet... (cached) no
0:11.57 checking for dnet_ntoa in -ldnet_stub... (cached) no
0:11.57 checking for gethostbyname... (cached) yes
0:11.58 checking for connect... (cached) yes
0:11.58 checking for remove... (cached) yes
0:11.58 checking for shmat... (cached) yes
0:11.58 checking for IceConnectionNumber in -lICE... (cached) yes
0:11.63 configure: error: compiler is incompatible with sanitize options
0:11.63 DEBUG:
0:11.63 DEBUG: configure: In function 'main':
0:11.63 DEBUG: configure:4301:15: error: '__thumb2__' undeclared (first use in
this function); did you mean '__unix__'?
0:11.63 DEBUG: configure:4301:15: note: each undeclared identifier is reported
only once for each function it appears in
0:11.63 DEBUG: configure: failed program was:
0:11.63 DEBUG: #line 4298 "configure"
0:11.63 DEBUG: #include "confdefs.h"
0:11.63 DEBUG:
0:11.63 DEBUG: int main() {
0:11.63 DEBUG: return sizeof(__thumb2__);
0:11.63 DEBUG: ; return 0; }
0:11.63 DEBUG: configure:5029: /usr/bin/ccache /usr/bin/gcc -std=gnu99 -o
conftest -Qunused-arguments conftest.c 1>&5
0:11.63 DEBUG: gcc: error: unrecognized command line option
'-Qunused-arguments'; did you mean '-Wunused-parameter'?
0:11.63 DEBUG: configure: failed program was:
0:11.63 DEBUG: #line 5022 "configure"
0:11.63 DEBUG: #include "confdefs.h"
0:11.63 DEBUG:
0:11.63 DEBUG: int main() {
0:11.63 DEBUG:
0:11.63 DEBUG: ; return 0; }
0:11.63 DEBUG: configure: error: compiler is incompatible with sanitize options
0:11.64 ERROR: old-configure failed
0:11.67 *** Fix above errors and then restart with\
0:11.67"/usr/bin/make -f client.mk build"
0:11.67 make[1]: *** [/projects/mozilla-unified/client.mk:250: configure]
Error 1
0:11.67 make: *** [client.mk:263:
/projects/mozilla-unified/obj-x86_64-pc-linux-gnu/config.status] Error 2
0:11.71 0 compiler warnings present.
0:11.72 ccache (direct) hit rate: 0.0%; (preprocessed) hit rate: 0.0%; miss
rate: 100.0%
```
Any idea what's causing it?
I'm on arch.
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
I'm not sure if the multiple- solution is going to be really working well.
>From the perspective of a gaia app developer that means that he has to inject
>manually a new for every library he wants to use.
That feels weird. I would rather expect a single that app controls
fully, sort of a master light switch.
Then, each library would report to the app when they're done. It could look
like this:
var readyPromises = [
L10n.init(),
Battery.init(),
Wifi.init(),
MainUI.init()
];
Promise.all(readyPromises).then(() => {
document.head.removeChild(lightSwitchElement);
});
This way library is not deciding if it's blocking displaying, it's the app
author who decides if he wants to prevent displaying until some meta is done.
===
Wrt. events, I'm on the Promise side over one-time events because the scenario
James described as "did I miss?".
So I'd love to have sth like:
document.mozFirstPaint.then();
if we're ok making this meta delay firstPaint.
===
As Wilson suggested, we may also want to add some information on what to
display until the page is painted for browser scenarios (like background color
etc.) - for gaia scenario I think we'll delay moving the window to foreground
until the promise is fulfilled.
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Friday, August 14, 2015 at 3:59:23 PM UTC-7, James Burke wrote: > There does not seem to be a need for extra APIs in the browser for > controlling layouts or paints using this approach: Great work James! I like that we can play with this approach right now, but I'm wondering if we should still pursue some API to facilitate this behavior for the Web. My concern here is that if we don't, we're basically saying that the right way to write webapps, is to put their content in a template and then inject the template into body when we're done with startup JS. That feels like a dirty hack, not sure how accessible it is, and it will literally do nothing in a scenario of any JS error. The API, even as a sugar coating on top of the heuristic you described, would not only solve the problems but also enable us to provide better UX for error case scenarios (your APP did not load properly, restart?) and open up possibilities for the engine to optimize for it (maybe HTML/CSS parsing should happen in parallel with init JS?). zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
API request: MutationObserver with querySelector
Hi,
One of the major use cases for MutationObserver is all kinds of libraries that
either shim APIs or provide intrinsic modifications to DOM experience.
Examples of such libraries may be:
* A library that provides Date/Time pickers only caring about
* A library that extends behavior of a particular web component from outside
* A library that extends behavior of common elements with particular attributes
* our l10n library only looks for element with data-l10n-id|data-l10n-args
* a resource API shim may be looking for with a given attribute
Unfortunately, at the moment, MutationObserver API makes it particularly hard
for libraries to narrow down the scope of elements that are monitored by them
which results in three things:
*) Higher CPU/power cost of running a MutationObserver on a DOM tree
*) More noise inside the MutationObserver callback
*) Requirement for fairly sophisticated filtering to get the right elements
The reason for so much noise is that there's no way to instrument
MutationObserver to notice only specific elements. The only filtering can be
done for attributes, but for node adding/removing MutationObserver reports
*all* elements and often in form of a DOMFragment which has to be filtered.
Example from our l10n library:
const observerConfig = {
attributes: true,
characterData: false,
childList: true,
subtree: true,
attributeFilter: ['data-l10n-id', 'data-l10n-args']
};
var mo = new MutationObserver(onMutations);
mo.observe(this.doc, observerConfig);
function onMutations(mutations) {
const targets = new Set();
for (let mutation of mutations) {
switch (mutation.type) {
case 'attributes':
targets.add(mutation.target);
break;
case 'childList':
for (let addedNode of mutation.addedNodes) {
if (addedNode.nodeType === addedNode.ELEMENT_NODE) {
if (addedNode.hasAttribute('data-l10n-id')) {
targets.add(addedNode);
}
if (addedNode.childElementCount) {
element.querySelectorAll('[data-l10n-id]').forEach(
elem => targets.add(elem));
}
}
}
break;
}
}
if (targets.size === 0) {
return;
}
translateElements(targets);
}
Proposal:
const observerConfig = {
attributes: true,
attributeFilter: ['data-l10n-id', 'data-l10n-args']
querySelector: '*[data-l10n-id]'
};
var mo = new MutationObserver(onMutations);
mo.observe(this.doc, observerConfig);
function onMutations(mutations) {
const targets = new Set();
for (let mutation of mutations) {
switch (mutation.type) {
case 'attributes':
targets.add(mutation.target);
break;
case 'childList':
for (let addedNode of mutation.addedNodes) {
targets.add(addedNode);
}
break;
}
}
if (targets.size === 0) {
return;
}
translateElements(targets);
}
And it's not only about cleaner code. In Firefox OS' Settings app, our
onMutations is fired hundreds of times as we construct DOM dynamically, while
l10n cares about 70 elements out of those.
I believe that there's a substantial value in extending MutationObserver API to
help with such filtering for all scenarios listed at the top and many similar
ones.
Would it be possible to do within MutationObserver API or would it be material
for a separate API?
Thanks,
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: API request: MutationObserver with querySelector
Reported: https://github.com/whatwg/dom/issues/77 zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Platform help needed for Firefox OS L10n/Intl
Hi all, There are two things in the platform that need a developer, which would significantly help Firefox OS L10n/Intl work. 1) Move navigator.mozHour12 to platform This is a shim [0] that currently requires us to give all apps that want to properly display time to elevate its privileges to have access to mozSettings, while reading this settings should not require any privs. Moving this to the platform would make our code more secure, and enable third-party apps to create better UX for the users. For desktop/android Gecko I think it's totally fine to leave it as undefined for now (which means that Intl API will use automatic value for a language) or we could take the data from the platform and follow it (which would be nice as well). Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1172732 2) MutationObserver callbacks should be called before executing defer scritps It seems like it should be easy to add, but I don't understand the codebase to write it myself. This one will allow us to write better shims for API's that we'd be standardizing. The reason why it hurts us right now is because all of our code is deferred and it means that we cannot rely on MutationObserver based shims to provide the experience matching the one a platform would give. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1180927 I would appreciate help with those two things. Thank you! zb. [0] https://github.com/mozilla-b2g/gaia/blob/2c14ecccd4c5b8c1217f2adc655ba75579d1/shared/js/date_time_helper.js ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
"non-missable" events, or multi-promises
There seem to be an interesting section in Promises doc from 2001 about
multi-state promises -
https://www.w3.org/2001/tag/doc/promises-guide#state-transitions
One of the things that we are working on is a spec for loading localization
resources into HTML, which resembles the example from this chapter.
I was thinking about something like:
linkElement.ready((resource) => {
console.log(resource.text());
});
and make when the language changes, I'd update the url in the link and the
callback would get called again when its loaded.
Is there any evolution of that proposal?
What's the current thinking about solving such cases?
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: "non-missable" events, or multi-promises
On Tuesday, September 22, 2015 at 3:02:21 AM UTC-7, smaug wrote: > That document is from 2015 ;) Oh. Fun! > The example in that chapter is "This property should return the same promise > every time it is retrieved, until the image moves backward from the > loaded state into the unloaded state. Once that occurs, a new promise is > created, representing the next transition to loaded." > So a new promise would be created. Oh, ok. So it's basically not the API I'm looking for :( > Why not use events for that? There is nothing wrong with events , and > https://www.w3.org/2001/tag/doc/promises-guide#when-not-to-use Events are missable. That means that writing async/lib code where you have to be ready to be executed at any point requires the following code: 1) Check if the target is in the fulfilled state 2) If yes, apply logic 3) Set up event listener With a Promise its: 1) Set a promise on the target and either: 2a) In the promise callback, set event listener, but only if it's not set yet or: 2b) Set an event listener now, but guard against double executing when event listener and promise are fulfilled at the same time. This sort of repeatable-promise, would reduce it to: 1) Set the repeatable promise on the target Sounds like it would make much easier to write async code without logic for preventing race conditions. Is there any other approach to that? zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: So, what's the point of Cu.import, these days?
On Tuesday, September 27, 2016 at 2:28:54 AM UTC-7, David Teller wrote:
> If I understand ES6 modules correctly, two imports from the same webpage
> will return the same module instance, right?
I don't think this is a correct statement across globals.
When you load two modules in one js context, maybe, but when you have two
browser.xul windows open and you load a JSM, it's shared between them.
> How hard would it be to consider all chrome code (of a JSRuntime) as a
> single webpage? That's pretty much a requirement for any module loader
> we would use for our chrome code.
So this opens up an interesting can of worms.
As we move into multi-process world, would we be interested in making our
module loading code make it less impossible to chunk chrome into separate
processes?
> I *think* that we can get rid all instances of the former, but I also
> think that it's a multi-year project to do it all across our code.
I don't see how or why would we want to get rid of all instances of the former.
It seems to me that we use the nature of singletons quite a lot - for example,
I'm working on a replacement for chrome registry for l10n resources and I use
runtime global cache by just having a single cache object in my JSM.
> @zb, do you think that it would be possible to have a migration path
> from jsm towards ES6 modules that would let us do it one module at a
> time? Let's assume for the moment that we can rewrite `Cu.import` to
> somehow expose ES6 modules as jsm modules.
I don't see a reason why wouldn't it be possible. We could even start by just
promoting the new method for new code.
> Also, how would you envision add-ons (which could add some kind of
> modules dynamically) in a world of ES6 modules?
I linked to the ECMA proposals that give us nested/conditional imports.
I believe that we should go this route.
> It is my understanding that ES6 modules, being designed for the web,
> don't expect any kind of sync I/O, and "just" block `onload`.
> Transitioning to ES6 modules would undoubtedly require some hackery here
> to pause the calling C++ code.
Quite the opposite.
The first version of es6 modules is synchronous, even static, from the
perspective of the user.
Only the import() function proposal introduces async way to load modules.
I see a huge value in both so I'd be happy if we implemented both internally
and through this participated in the evolution of the import function proposal.
personal preference would be to not settle on the intermittent module loading
API. If we want to move, let's go all the way and do this right.
One idea that came to mind for how could we differentiate between singleton
loading and in-context loading using statements would be to differentiate by
path.
Not sure if it feels right or a dirty hack, but sth like this:
import { Registry } from 'resource://gre/modules/L10nRegistry.jsm';
would work like Cu.import,
import { Registry } from 'resource://gre/modules/my-file.js';
would load my-file in-context.
Does it sound like a cool way of solving it or a terrible way of complicating
it?
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: So, what's the point of Cu.import, these days?
On Tuesday, September 27, 2016 at 2:01:09 PM UTC-7, David Teller wrote:
> "why": because you wrote "The former is a more tricky." in your previous
> message. If it's not, I'm quite happy to not remove them :)
>
> For reference, "the former" is a snippet such as:
>
> if (needed) {
> Cu.import(...);
> }
>
> to which I would add
>
> function foo() {
> Cu.import(...);
> }
It's tricky for migration, but it's extremely useful for performance and memory
consumption.
I believe we want both nested and conditional imports.
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Should MutationObserver ensure HTML file nodes are run through it before they're injected in DOM?
I'm trying to use MutationObserver to do runtime localization of the nodes that are provided by an HTML file. I register the mutation observer on document at it's readyState=loading and in result all nodes that are in HTML files are reported to my callback. That's cool. Now, usually, firstPaint happen after this, so if I translate those nodes, all I see on firstPaint is a stable screen with properly translated nodes. The order seems to be: 1) observer registered 2) nodes injected into DOM 3) observer's callback translates the nodes 4) firstPaint But when I test this on a slow device (Keon) and on a rather complex app (Settings), every now and then I see a flash of untranslated content before the nodes are being translated by the mutation observer's callback. It just seems that in those cases the order is: 1) observer registered 2) nodes injected into DOM 3) firstPaint 4) obsever's callback translates the nodes Question: should mutationobserver's callback be run on those nodes before firstPaint? Or Question 2: should mutationobserver's callback be run on those nodes before they are injected into DOM? Thanks, zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Mutations from Parser handled after DOMContentLoaded?
Hi all, I have a question about MO behavior. >From what I understand, MutationObserver API is designed in a way that is >supposed to guarantee two things that I need: 1) That if I have a MO set on the document during readyState=loading, then all consequent elements injected by Parser into DOM will go through MO before layout 2) And that they will block DOMContentLoaded The first behavior is crucial for client side localization so that we can translate the node that is being injected before any frame creation/layout happens. I'm still not sure if that's the case and I'm not even sure how to test if our implementation guarantees that. But now, I have more doubts because it seems that we don't do 2). My test works like this - https://pastebin.mozilla.org/8838694 I first start a MutationObserver inline and register it on document.head. Whenever link with rel=localization is inserted I add `ready` property to it. Then I run a deferred script (in my tests I use external scripts, but I inlined them for the testcase) which collects all links with rel=localization from document.head and operates on their `ready` property which should be, according to my logic, always there. When I test this, I get nondeterministic behavior with ready being set in ~80% of reloads and in 20% onAddedHeadElement is executed after the deferred script. Is that a bug? Because if it's not, it feels like it should be. Or am I wrong? zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mutations from Parser handled after DOMContentLoaded?
On Monday, July 6, 2015 at 12:48:33 PM UTC-7, smaug wrote:
> I don't know what "have a MO set on the document during readyState=loading"
> actually means.
Document has three loading states - loading, interactive, complete[0].
I'm initializing MO during loading stage, so that I have a chance to mutate
elements before it gets to interactive stage.
> MutationObserver callback is called at the end of microtask, so end of
> outermost script execution or end of a task in general.
I don't think that's what is happening right now. I have an extended example at
the end of this post.
> And MutationObserver has nothing to do with DOMContentLoaded.
I understand that. But MO fired synchronously in document.readyState=='loading'
should compete it's callback before DOMContentLoaded I believe.
> I don't see any elements in your example
Yeah, I overminimized my testcase. Below is a better one :)
> Oh, you want to ensure MutationObservers are called before some script is
> executed? That is indeed still a bug, Bug 789315.
Not necessarily, although that would probably fix my problem.
I expect that if I have MO set during the time when Parser is parsing HTML,
then MO's callback should be called when the element is injected into DOM and
that means before DOMContentLoaded is called.
It just seems logical to not call DOMContentLoaded (and not fire deferred
scripts in result) until MO callback is executed on elements injected into DOM
by Parser. I believe that it's not the case right now.
The proper testcase: http://labs.braniecki.net/mo/
Around 80% of time my console looks like this:
1) mo start mo.js:3:3
2) mo onMutations mo.js:16:5
3) setting ready on the element mo.js:30:7
4) main.js starts main.js:1:1
5) Promise { : "fulfilled", : Response }
Which seems to be the right order. 1/2/3 are synchronously launched, 3 is fired
when Parser injects link into DOM, and then DOMContentLoaded triggers execution
of deferred script in 4) and in 5) we capture link.ready as a promise.
Around 20% of time my console looks like this:
1) mo start mo.js:3:3
2) main.js starts main.js:1:1
3) undefined main.js:5:1
4) mo onMutations mo.js:16:5
5) setting ready on the element
which seems to be wrong. MutationObserver starts in 1, but then
DOMContentLoaded triggers deferred main.js in 2 before MO callback is executed.
With this behavior it seems that there's no way to ensure that deferred scripts
operate on DOM already altered by synchronously executed MO callbacks, which is
what enables us to prototype and shim DOM related API's.
Does my logic make any sense?
zb.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Mutations from Parser handled after DOMContentLoaded?
We took it to the stre... IRC, and in result of that I filed to bugs: 1) https://www.w3.org/Bugs/Public/show_bug.cgi?id=28920 2) https://bugzilla.mozilla.org/show_bug.cgi?id=1180927 zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
This is something I've been asking for for quite a while. We have this state with runtime localization where we have to do backflips in order to win the race with Gecko to firstPaint. I filed a bug for getting an API to prevent frame creation [0] and got a response that display: none should do this. Because I couldn't verify any gain and I hit the "white page on load" problem I gave up. My understanding is that we have two topics here: 1) We need a way to inject asynchronous javascript that will take DOM from HTML, modify it and report when done. There may be multiple code pieces that want to do this and it should delay frame creation and layout until this code is done. That concept that a given app wants to prevent frame creation until its JS reports being done would help a lot of frameworks like react, angular and localization related as well. The challenge is that ideally we would like to not have to inject synchronous script to enable that. So any form of tag or manifest entry would be better than DOM API for notifying the platform that this page wants to delay. We may also want to think about a timeout in case things go south, but I'm not sure if after the timeout we should paint whatever we have (almost certainly a broken and useless UI) or should we paint a user-friendly "This page is broken. Restart? Reinstall? Remove? Report?" dialog. >From the perspective of Gaia UI I'd say the latter. 2) We want to bring app to foreground/paint it only when the app's chrome is visually complete. This is easier since we now have the performance marks and they nicely correspond to when the UI of the app is meaningful. The only challenge here is that the marks from the website are representing app code state and intention. "navigationLoaded" which indicates that chrome code is ready will overlap with "start frame creation" from 1) but doesn't mean that frame/layout/firstPaint happened. So on one hand we could tie Gaia system to bring app to foreground on this even, on the other hand, ideally we'd like to tie that event to gecko's frame/layout and then bring the app to foreground on firstPaint. So if the display:none strategy does prevent frame/layout, I see the solution as such: 1) We add to our apps 2) We switch body.style.display = 'block'; on navigationLoaded 3) We need an event from Gecko when *after* step (2) it painted the document 4) We need to switch in the system to only bring apps to foreground in reaction to step (3) That should solve it? On top of that we could achieve two more features: a) Look from System into app's document's DOM on DOMContentLoaded and if has display='none' wait with bringing it to the foreground for navigationLoaded b) If document's body has display='none' and doesn't fire up navigationLoaded in a certain amount of time, stop script execution of that document and display "Unfortunately this app failed to load" user-friendly dialog. What do you think? zb. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1176924 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Saturday, August 1, 2015 at 3:01:39 PM UTC-7, Jonas Sicking wrote: > On Sat, Aug 1, 2015 at 12:30 PM, Zibi Braniecki wrote: > > 2) We want to bring app to foreground/paint it only when the app's chrome > > is visually complete. > > I would very much want this. Right now, during a navigation from page > A to page B I believe that we render A until we've parsed B's opening > tag. It would be great if we enabled pages to communicate to > the browser when they are actually ready to render. Agree. Working on the performance.mark events (Eli may have more insight) made me realize that we generally have two types of apps: 1) Apps that have a defined and useful chrome. Example is SMS app. When it's chrome is ready, we should paint and show it to the user, and only then work on loading the content (list of text messages). We should also take a screenshot with the chrome only (to prevent data leaking) and possibly cache chrome for quick-display. 2) Apps that are useless without content. Example is Settings app where chrome is literally just the top header. For those, the firstPaint/foreground should happen only on visuallyLoaded - when the visible portion of content is loaded because displaying it without doesn't make sense. So maybe we would need another event that the website fires to indicate when it for paint/cache/screenshot. zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Sunday, August 2, 2015 at 2:03:28 AM UTC-7, Robert O'Callahan wrote: > On Sun, Aug 2, 2015 at 11:58 AM, Zibi Braniecki wrote: > > > So maybe we would need another event that the website fires to indicate > > when it for paint/cache/screenshot. > > > > Assuming pages have an easy way to block the 'load' event until they're > ready, can this just be the 'load' event? you mean window.load or performance.mark fullyLoaded? If the former, I'm not sure how a page can control when the loaded is fired. If the latter, then it's not a good one. fullyLoaded is supposed to be fired when the page finished loading background data needed for operation. zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Sunday, August 2, 2015 at 10:47:26 PM UTC-7, Wilson Page wrote: > Are we expecting that this will reduce unwanted layout/paint cycles on the > critical path and thus minimise the 'white flash of doom'? Absolutely. I believe that that's the primary goal, to replace the current race condition between app's JS and the engine to firstPaint. > If the user has to see anything before the new 'please-draw-me' event, we'd > probably like to see the app's background painted with the primary theme > color, or some kind of splash-screen image. Anything but the signature 'I'm > a clunky old website' white flash :) That's a cool idea. I'd suggest that for Gaia we'd prefer not to move the app to foreground at all, or do some smart calculations to know that the app starts on average in 600ms, so start the 200ms transition animation after 400ms. But for web apps in the browser that would make a lot of sense. zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
[PSA] Fluent can now be used to localize UA Widgets
Hi all, Thanks to the work of James Teh [:Jamie] in bug 1659625, you can now use Fluent to localize UA Widgets. You'll need to create a custom `DOMLocalization` or `Localization` instance, and use `connectRoot` and `disconnectRoot` to integrate it into the UA Widget's lifecycle. An example of such integration landed as https://hg.mozilla.org/mozilla-central/rev/0aa1e618b7a3 As a reminder, DTD is deprecated [0]. The priority is to get rid of the remaining 200 DTD entries on the startup path [1], and then the rest [2]. Please, help us de-DTD the codebase by migrating all available DTDs to Fluent. Thank you, zb. [0] https://groups.google.com/g/mozilla.dev.platform/c/3RFCrI0uSCE/m/KoRLcrXQDwAJ [1] https://www.arewefluentyet.com/?milestone=M1 [2] https://www.arewefluentyet.com/?milestone=M3 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
`general.useragent.locale` is no more. All hail `intl.locale.requested`
Hi all, We just landed a major patch which replaces `general.useragent.locale` pref with a new pref `intl.locale.requested`. Historically, `general.useragent.locale` has been widely used to set a locale for Firefox UI. This year, we introduced a full new API called mozilla::intl::LocaleService which allows for setting and reading via setRequestedLocales and getRequestedLocales, respectively. Behind some linting and checking, the API still used `general.useragent.locale` which limited us due to the nature of the pref and how it stored data. With the change, we introduce a new pref - `intl.locale.requested`, which can be set in the same manner if needed, but can also handle a list of locales separated via `,` character and is validated to accept only well-formed BCP47 language tags [1] making our locale handling much more flexible and resilient. This is one of the last major changes in the grand rewrite of how Gecko handles locales and language negotiation. If you need to read/write the requested locales it is *highly* preferred that you use the (mozI)LocaleService API over reading/writing to the pref itself, but if you must, the code will be able to handle your change with grace. Over last months we removed all direct writes/reads of the pref, so I hope there is nothing remaining, and we also introduced a migration code in nsBrowserGlue for 59 users, but if you happen to encounter a regression, please report it and CC me. If you have any questions about it, let me know! zb. [1] https://tools.ietf.org/html/bcp47 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: `general.useragent.locale` is no more. All hail `intl.locale.requested`
Yes! Thank you for bringing it up. I forgot to mention it in my original message. We also removed `intl.locale.matchOS` and turned an empty `intl.locale.requested` to mean "use OS locales" [0]. zb. [0] https://hg.mozilla.org/integration/autoland/file/tip/intl/locale/LocaleService.cpp#l75 On Tue, Dec 5, 2017 at 3:47 PM, Mike Hommey wrote: > On Tue, Dec 05, 2017 at 03:15:06PM -0800, Zibi Braniecki (Gandalf) wrote: > > Hi all, > > > > We just landed a major patch which replaces `general.useragent.locale` > pref > > with a new pref `intl.locale.requested`. > > > > Historically, `general.useragent.locale` has been widely used to set a > > locale for Firefox UI. > > > > This year, we introduced a full new API called > mozilla::intl::LocaleService > > which allows for setting and reading via setRequestedLocales and > > getRequestedLocales, respectively. > > > > Behind some linting and checking, the API still used > > `general.useragent.locale` which limited us due to the nature of the pref > > and how it stored data. > > > > With the change, we introduce a new pref - `intl.locale.requested`, which > > can be set in the same manner if needed, but can also handle a list of > > locales separated via `,` character and is validated to accept only > > well-formed BCP47 language tags [1] making our locale handling much more > > flexible and resilient. > > > > This is one of the last major changes in the grand rewrite of how Gecko > > handles locales and language negotiation. > > > > If you need to read/write the requested locales it is *highly* preferred > > that you use the (mozI)LocaleService API over reading/writing to the pref > > itself, but if you must, the code will be able to handle your change with > > grace. > > > > Over last months we removed all direct writes/reads of the pref, so I > hope > > there is nothing remaining, and we also introduced a migration code in > > nsBrowserGlue for 59 users, but if you happen to encounter a regression, > > please report it and CC me. > > > > If you have any questions about it, let me know! > > Any change wrt intl.locale.matchOS? > > Mike > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
BCP47 normalization of Language Tags in Gecko/Firefox
Hi all!
A couple changes just landed in Gecko that will tighten our handling of
language tags and locales to BCP47 standard.
tl;dr:
- Use mozilla::locale::Locale for any operations on Locale codes in C++
- Expect LocaleService::NegotiateLanguages to return canonicalized BCP47
langauge tags
== Locale ==
We gained mozilla::intl::Locale class [0] which allows any C++ code to
validate, normalize and parse language tags.
Please, start using this code whenever you find yourself having to work
with language tags and analyze them.
For example instead of trying to write `langTag.Substring(0,
2).Equals("en")` which is insanely brittle, use:
```
Locale loc = Locale(langTag);
loc.GetLanguage().Equals("en");
```
You can also compare directly `loc == loc2` or using `.Match` which can
take ranges (to make `en` be treated as `en-*-*-*` and match `en-US`)
For JS code, we just advanced the `Intl.Locale` proposal to Stage 3 [0] at
this weeks TC39 meeting and will implement it in SpiderMonkey soon [1].
The locale class implements a direct subset of BCP47 and will be expanded
over time to handle more (all?) of it.
As we will want to start using Unicode Extension Keys around the codebase,
it becomes important that we can rely on all language tags being correctly
parsed and that means that we don't have DIY code around our codebase that
attempts to parse them on its own.
== Language Negotiation ==
There is also a change to our language negotiation handled by
mozilla::locale::LocaleService::NegotiateLanguages and
`Services.locale.negotiateLanguages`.
We now canonicalize the output (because we use the Locale class mentioned
above). That means that if you pass `ES-es` language tag, we'll return
`es-ES`.
It is important that we conform our codebase to the BCP47 standard and if
you expect to face non-canonicalized code, you can always use Locale class
or `Intl.getCanonicalLocales` ECMA402 API to get the canonicalized version
of any locale list.
If you have any questions, please, let me know!
zb.
p.s. We still support *one* extension to BCP47 which is 3-letter variants,
and we do this exclusively for the `ja-JP-mac` case. There's a conversation
about how to get rid of it [3] as it's the sole reason we have to maintain
both `LocaleService::GetAppLocalesAsLangTags` and
`LocaleService::GetAppLocalesAsBCP47`.
[0]
https://hg.mozilla.org/integration/autoland/file/tip/intl/locale/MozLocale.h#l16
[1] https://github.com/tc39/proposal-intl-locale/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1433303
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1424953
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review
On Thu, Mar 8, 2018 at 7:09 PM, Bobby Holley wrote: > I just looked at the first 10 methods/attributes on that interface. None > of them are remotely performance-sensitive, and several are test-only. If > we see certain methods on it show up in profiles, we should move those > methods to WebIDL, rather than converting things wholesale per-interface. > > Are you suggesting that we build two IDLs per interface - one for perfomance-bound methods and the other for "non-performance-critical" ones? I'm just a used of XPIDL/WebIDL but I noticed that almost every interface I build or use has a mixture of those two types. >From that perspective, ability to write a single IDL file and mark which functions should be perf-critical (or the opposite) would be significantly better UX and more fine-tunable over time. But if your recommendation is to go for two, I would really appreciate a tutorial explaining how to design a C++ and JS API with those two IDLs separating perf-critical methods from others. zb. p.s. I understand your concern about sinking time into developing a WebIDL for XPIDL replacement. At the same time, my understanding is that no matter how much time something took in the past, we (in general) design our architecture for a much longer future. So if we can introduce something soon that will allow all new APIs to benefit from it, the argument of how many APIs we already have that use the old model is diminishing. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Everything you always wanted to know about I18n/L10n/L12y, but....
Hi! I'm very proud to introduce the latest addition to our family of "explain ourselves" efforts - shiny, new developer docs about locale management, internationalization and localization practices at Mozilla. https://firefox-source-docs.mozilla.org/intl/index.html We put a lot of effort to make it a "cup of coffee per topic" size wise, and hope you'll get to easily identify the topics relevant to your work. The first topic - Locale Management - is for that time when you need to make your code work with languages, select them, manage, negotiate etc. The other two - UI Internationalization and Localization - are important if you ever work with any front-end code at Mozilla. We focused on Firefox and Gecko apps, but almost everything applies universally across all of our portfolio. I'd love to hear your feedback on whether we are making progress in turning complex and hermetic field of knowledge more approachable and easier to work with If you any questions, please let me know! We'll do our best to keep those documents, and our extensive in-source-code docs in sync and up to date. Enjoy your coffee :) zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Pseudolocalization in Firefox Nightly!
Hi all! We've just landed a new hot developer-oriented feature in Firefox Nightly - Pseudolocalization. Pseudolocalization allows developers to quickly test their UI against fake localizations helping us discover internationalization issues earlier in the cycle. You can find an introduction video here: https://www.youtube.com/watch?v=pmT9PINv6nE An introduction blog post here: https://diary.braniecki.net/2018/06/07/pseudolocalization-in-firefox/ And documentation here: https://firefox-source-docs.mozilla.org/intl/l10n/docs/l10n/fluent_tutorial.html#pseudolocalization The functionality is directly related to the new localization framework - Fluent - and in result works in areas covered by Fluent - mainly Preferences at the moment. As Fluent becomes available in other parts of our codebase, pseudolocalization will come with it. We're looking forward to hear your feedback and requests for more features! zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
[L10n][BiDi] Fluent now controls content directionality
Hi all, A small update from the Fluent world - with landing of bug 1480798 Fluent now controls the directionality of its roots. That means that you don't need to do any special magic for RTL locales, as we will set `localedir` and `dir` (XUL and HTML) attributes on the document element and flip it correctly in case of a locale change. For most of the layout it is advised to write as much of it as possible in a directionality-independent way (so first/last rather than left/right), but if special rules for direction are necessary, `html[dir=rtl]` and `html[dir=ltr]` should be enough! Once exception is pseudolocales, where strategy `bidi` does not currently automatically trigger directionality switch. I filled bug 1481325 to fix that. Enjoy, zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Updates to mozilla/intl/mozILocaleService and mozilla/intl/mozIOSPreferences
Hi all, A quick update on the LocaleService and OSPreferences APIs. We just landed an update [0] that utilizes recently introduced new XPIDL feature of handling Arrays[1]! That means that we were able to turn all `getX` and `setX` methods into properties, which means that instead of `Services.locale.getRequestedLocales` and `Services.locale.setRequestedLocales` you'll now have `Services.locale.requestedLocales` and so on. The change for OSPreferences will land soon [2]. The new APIs: - LocaleService.requestedLocales (rw) - LocaleService.availableLocales (rw) - LocaleService.packagedLocales (ro) - LocaleService.regionalPrefsLocales (ro) - OSPreferences.systemLocales (ro) - OSPreferences.regionalPrefsLocales (ro) Documentation is available in the IDL files: - https://searchfox.org/mozilla-central/source/intl/locale/mozILocaleService.idl - https://searchfox.org/mozilla-central/source/intl/locale/mozIOSPreferences.idl and in the docs: https://firefox-source-docs.mozilla.org/intl/locale.html Also, PSA - the new Array<> API is awesome and you should switch to it! Cheers, zb. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1491394 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1474369 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1493220 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Deprecating DTD for localization in Firefox UI
Hi all, tl;dr: Please use Fluent instead of adding or changing existing DTD strings. == DTD and Fluent == DTD has been used as the core localization format and API inside of Firefox since the dawn of Mozilla, allowing us to localize our XUL and other XML files. Unfortunately, DTD comes with a set of quite painful limitations, including the so called Yellow Screen of Death which causes a crash at startup and requires a complicated manual process by each user to recover. We’ve recently been affected by this on beta [1]. For a couple years now, we’ve been working on a replacement for DTD - a new localization system called Fluent [2] which (among other things) addresses the shortcomings of DTD. == Deprecating DTD for localization in browser chrome == Now that Fluent meets the performance requirements to replace DTD, we would like to deprecate the DTD file format as a localization mechanism in Firefox. Please could you: 1. Avoid introducing any new DTD strings in mozilla-central. 2. If existing DTD strings would need to be changed, migrate them to Fluent [3] instead of updating the message identifier in DTD. There are a few small areas where integrating Fluent is not entirely trivial (most notably UA widgets) and those will be exempted from the deprecation. In case you believe there are technical reasons to continue using DTD in your project, please consult fluent-reviewers group [4], which has been recently extended with additions of Jared Wein, Gijs Kruitbosch and Edward Lee. They can be reached in #fluent on Slack or fluent-reviewers on phabricator. The change does not affect release or beta uplifts, since we don’t change strings in those. ESR uplifts will be exempted from the deprecation. == Dashboard == In order to visualize our progress, we recently updated our dashboard: https://arewefluentyet.com/ The new version introduces three milestones: M1 - Removal of DTD from browser.xhtml - addresses Yellow Screen of Death [5] M2 - Migration of the startup path to Fluent [6] Mx - Migration of the whole mozilla-central to Fluent [7] Additional milestones may be added as we identify them. Each one of these milestones will enable a set of new features for Firefox, and deprecating DTD for localization is aiming to help us achieve them sooner. If you have any questions, let me know! Cheers, zb. [1] https://www.reddit.com/r/firefox/comments/d5wq0z/firefox_crashes_on_browser_startup_and_flashes/ [2] https://firefox-source-docs.mozilla.org/intl/l10n/l10n/index.html [3] https://firefox-source-docs.mozilla.org/intl/l10n/l10n/fluent_migrations.html [4] fluent-reviewers group (#fluent on Slack): - Francesco Lodolo - Jared Wein - Gijs Kruitbosch - Edward Lee - Axel Hecht - Staś Małolepszy - Zibi Braniecki [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1579477 [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1501881 [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1581212 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Semantic Locale and Language management in Gecko
Hi all!
If you ever need to work with language/locale identifiers, we now have a
clean API to use for all Rust, C++ and JavaScript.
The most common scenario in which you may encounter the need is when you
want to verify that, say, Firefox UI locale is English, or that the
regional variant is "US".
Historically you'd write this code as:
```js
const locale = Services.locale.appLocaleAsBCP47;
if (locale.substr(0, 2) == "en") {
// it's English!
}
```
Unicode Language Identifiers are a bit more complicated, and such DIY code
is likely to break in all sorts of creative ways.
You can read the complete spec [0] and implement some of that parsing
yourself, but there's now an easier way - Locale API!
=== How to use ==
The API supports parsing, canonicalizing, validating, serializing,
modifying etc, but here I'm just going to show how testing for a subtag
works:
1) JavaScript
Andre Bargul implemented `Intl.Locale` API, part of the upcoming edition of
EcmaScript 2020! This API allows you to parse the language identifier
string and operate on it semantically:
```js
const locale = new Locale(Services.locale.appLocaleAsBCP47);
if (locale.language == "en") {
// it's English!
}
```
You can find full docs here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Locale
2) C++
```cpp
nsAutoCString locale
LocaleService::GetInstance()->GetAppLocaleAsBCP47(locale);
Locale loc = Locale(locale);
if (loc.GetLanguage().Equals("en")) {
// it's English!
}
```
You can find full docs here:
https://searchfox.org/mozilla-central/source/intl/locale/MozLocale.h
3) Rust
```rust
// No access to LocaleService yet!
let locale = LanguageIdentifier::try_from("en-US").unwrap_or_default();
if (locale.language() == "en") {
// it's English!
}
```
You can find full docs here: https://docs.rs/unic-langid/0.8.0/unic_langid/
== Why it's important ==
In order to improve our handling of Firefox localization, multilingualism
and internationalization, we need to be able to operate on the whole range
of possible language and locale identifiers.
With an API for operating on them centralized in a single place, we can
extend our features providing improved support for our users and their
regional, linguistic and cultural preferences encoded as part of the
identifier (for example: "en-DE-u-hc-h12-fw-sun" is English in Germany with
12h clock with first day of the week set to Sunday)
Before we can enable such customizations, we need to clean up our codebase
to make sure that all code that works with those identifiers will not break.
It may sound theoretical, but there are real cases where major software
(Android) had to implement terrible dirty hacks in their code to support
pseudolocalization and language fallbacking because the codebase was
sprinkled with DYI language identifier parsing and just could handle the
standard.
Fortunately, Gecko is already much cleaner than that, and we only have a
small number of places which we have to switch to Locale API, but that code
is hard to find or lint for, and we'd like to make sure that all new code
uses the correct logic.
== Language Negotiation ==
Tangible to that is the topic of language negotiation. If you ever need to
match one language identifier to another, please use `Locale::Matches`.
If you need to negotiate, use `LocaleService::NegotiateLanguages`.
== Next steps ==
Over the next months we'll be looking to migrate the remaining cases around
our codebase [1]. Then we'll want to turn on Unicode Extensions in
MozLocale class.
We'll also want to switch LocaleService API to return instances of `Locale`
in C++ and JS.
If you have any questions or feedback,
please let me know!
Thank you,
zb.
[0] https://unicode.org/reports/tr35/#Identifiers
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1433329
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Firefox Nightly Fluent core moved to Rust
Hi all, This is a PSA about the change that landed last night in bug 1560038 [0]. We migrated the core of Fluent Localization System in Gecko from JavaScript [1] to Rust [2]. The expected benefits are: - Lays groundwork for shared memory for Fluent (Fission) (next steps in bug 1613705 [3]) - Removal of JS/XPCOM engine bootstrap from startup path for Fluent/DOM - Slight performance improvement with hopes for greater wins in bug 1613705 [3]. - Full AST parser allows for better diagnostics and error reporting This is a change that should result in no observable difference in behavior but since it is a significant change in the core of the system I'd like to ask all users of Nightly to watch for any unexpected behavior related to localization and report it on Bugzilla (Core::Internationalization) or on Matrix (#l10n-dev:mozilla.org). Thank you! zb. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1560038 [1] https://github.com/projectfluent/fluent.js/tree/master/fluent-bundle [2] https://crates.io/crates/fluent [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1613705 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
