MozillaWiki - User contributions [en]

Platform/XML Rewrite

2021-06-07T07:19:32Z

Hsivonen: /* Goals */ Clarify the notification part

("I" in this page refers to hsivonen.)

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Align notification behavior with the HTML parser instead of deferring append notification for legacy reasons (after the change, we wouldn't have the state where DOM contains nodes that have been appended but whose append notifications haven't been posted)
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from sinks
* Moving chrome prototype parser or XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

==XML Web content loading==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::XmlParser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::XmlStreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::XmlTreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::TreeOpExecutor)

===Character encodings===

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an unconventional API for plugging in other decoders.

We should continue to handle characters encodings outside expat, but we should handle the buffering in clearer code than the current nsScanner that wasn't meant for XML to begin with and is now a very strange way to handle buffering before data reaches expat.

===Connecting handlers to expat===

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::XmlTreeOpGenerator should know how to register itself as the handler of various expat callbacks. This way, we don't need a layer of virtual calls on right on top of expat's function pointer-based calls.

===Dealing with stream data off the main thread===

mozilla::XmlStreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

===Dealing with entity references off the main thread===

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything. Failing that, we could bake the data into the shared library so that it's available as static data on any thread.

===Lack of actual speculation===

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::XmlStreamParser: mozilla::XmlMainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

==Parsing XML that's not Web content-like==

We use expat for 1) XHR, 2) XML Web content, 3) Firefox UI files using the prototype parser and 4) for XSLT programs. Moving the last two off-the-main-thread may not be worthwhile.

==Fragment parsing==

On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths.

==XSLT and XHR==

The document that is given as input to an XSLT program and the document loaded via XHR are currently built by nsXMLContentSink. In the new world, they'd use the tree op mechanism instead like other things that currently use nsXMLContentSink.

==Showing a common interface to nsDocument==

nsIParser is pointlessly crufty and COMtaminated. There should be a new non-XPCOM abstract class that shows the commonality of XML and HTML parsing to nsDocument but no cruft. The new interface should look something like this:

class mozilla::parser::AParser {
virtual void setCharsetAndSource(mozilla::Encoding* aEncoding, uint32_t aSource) = 0;
virtual nsIStreamListener* GetStreamListener() = 0;
virtual void UnblockParser() = 0;
virtual void Start(nsIRequestObserver* aObserver) = 0; // Replaces Parse()
virtual void Terminate() = 0;
// possibly document.write and script execution stuff that'd be no-op in the XML case
};

Both mozilla::XmlParser and nsHtml5Parser would inherit from this abstract class.

==Alternatives==

Both the input stage to the XML parser (nsParser, nsScanner) and the output stage (nsXMLContentSink) could be rewritten to address legacy issues without also moving expat off the main thread.

Platform/XML Rewrite

2021-06-07T07:17:40Z

Hsivonen: Note that moving expat off-the-main-thread is not a must for some of the other improvements

("I" in this page refers to hsivonen.)

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Align notification behavior with the HTML parser instead of deferring append notification for legacy reasons
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from sinks
* Moving chrome prototype parser or XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

==XML Web content loading==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::XmlParser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::XmlStreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::XmlTreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::TreeOpExecutor)

===Character encodings===

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an unconventional API for plugging in other decoders.

We should continue to handle characters encodings outside expat, but we should handle the buffering in clearer code than the current nsScanner that wasn't meant for XML to begin with and is now a very strange way to handle buffering before data reaches expat.

===Connecting handlers to expat===

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::XmlTreeOpGenerator should know how to register itself as the handler of various expat callbacks. This way, we don't need a layer of virtual calls on right on top of expat's function pointer-based calls.

===Dealing with stream data off the main thread===

mozilla::XmlStreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

===Dealing with entity references off the main thread===

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything. Failing that, we could bake the data into the shared library so that it's available as static data on any thread.

===Lack of actual speculation===

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::XmlStreamParser: mozilla::XmlMainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

==Parsing XML that's not Web content-like==

We use expat for 1) XHR, 2) XML Web content, 3) Firefox UI files using the prototype parser and 4) for XSLT programs. Moving the last two off-the-main-thread may not be worthwhile.

==Fragment parsing==

On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths.

==XSLT and XHR==

The document that is given as input to an XSLT program and the document loaded via XHR are currently built by nsXMLContentSink. In the new world, they'd use the tree op mechanism instead like other things that currently use nsXMLContentSink.

==Showing a common interface to nsDocument==

nsIParser is pointlessly crufty and COMtaminated. There should be a new non-XPCOM abstract class that shows the commonality of XML and HTML parsing to nsDocument but no cruft. The new interface should look something like this:

class mozilla::parser::AParser {
virtual void setCharsetAndSource(mozilla::Encoding* aEncoding, uint32_t aSource) = 0;
virtual nsIStreamListener* GetStreamListener() = 0;
virtual void UnblockParser() = 0;
virtual void Start(nsIRequestObserver* aObserver) = 0; // Replaces Parse()
virtual void Terminate() = 0;
// possibly document.write and script execution stuff that'd be no-op in the XML case
};

Both mozilla::XmlParser and nsHtml5Parser would inherit from this abstract class.

==Alternatives==

Both the input stage to the XML parser (nsParser, nsScanner) and the output stage (nsXMLContentSink) could be rewritten to address legacy issues without also moving expat off the main thread.

Platform/XML Rewrite

2021-06-07T07:15:51Z

Hsivonen: Reword flush item

("I" in this page refers to hsivonen.)

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Align notification behavior with the HTML parser instead of deferring append notification for legacy reasons
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from sinks
* Moving chrome prototype parser or XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

==XML Web content loading==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::XmlParser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::XmlStreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::XmlTreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::TreeOpExecutor)

===Character encodings===

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an unconventional API for plugging in other decoders.

We should continue to handle characters encodings outside expat, but we should handle the buffering in clearer code than the current nsScanner that wasn't meant for XML to begin with and is now a very strange way to handle buffering before data reaches expat.

===Connecting handlers to expat===

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::XmlTreeOpGenerator should know how to register itself as the handler of various expat callbacks. This way, we don't need a layer of virtual calls on right on top of expat's function pointer-based calls.

===Dealing with stream data off the main thread===

mozilla::XmlStreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

===Dealing with entity references off the main thread===

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything. Failing that, we could bake the data into the shared library so that it's available as static data on any thread.

===Lack of actual speculation===

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::XmlStreamParser: mozilla::XmlMainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

==Parsing XML that's not Web content-like==

We use expat for 1) XHR, 2) XML Web content, 3) Firefox UI files using the prototype parser and 4) for XSLT programs. Moving the last two off-the-main-thread may not be worthwhile.

==Fragment parsing==

On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths.

==XSLT and XHR==

The document that is given as input to an XSLT program and the document loaded via XHR are currently built by nsXMLContentSink. In the new world, they'd use the tree op mechanism instead like other things that currently use nsXMLContentSink.

==Showing a common interface to nsDocument==

nsIParser is pointlessly crufty and COMtaminated. There should be a new non-XPCOM abstract class that shows the commonality of XML and HTML parsing to nsDocument but no cruft. The new interface should look something like this:

class mozilla::parser::AParser {
virtual void setCharsetAndSource(mozilla::Encoding* aEncoding, uint32_t aSource) = 0;
virtual nsIStreamListener* GetStreamListener() = 0;
virtual void UnblockParser() = 0;
virtual void Start(nsIRequestObserver* aObserver) = 0; // Replaces Parse()
virtual void Terminate() = 0;
// possibly document.write and script execution stuff that'd be no-op in the XML case
};

Both mozilla::XmlParser and nsHtml5Parser would inherit from this abstract class.

Platform/XML Rewrite

2021-06-02T13:26:17Z

Hsivonen: Remove mention of SAX and XBL, and otherwise update the plan for 2021

("I" in this page refers to hsivonen.)

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Get rid of content-initiated flushes
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from sinks
* Moving chrome prototype parser or XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

==XML Web content loading==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::XmlParser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::XmlStreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::XmlTreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::TreeOpExecutor)

===Character encodings===

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an unconventional API for plugging in other decoders.

We should continue to handle characters encodings outside expat, but we should handle the buffering in clearer code than the current nsScanner that wasn't meant for XML to begin with and is now a very strange way to handle buffering before data reaches expat.

===Connecting handlers to expat===

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::XmlTreeOpGenerator should know how to register itself as the handler of various expat callbacks. This way, we don't need a layer of virtual calls on right on top of expat's function pointer-based calls.

===Dealing with stream data off the main thread===

mozilla::XmlStreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

===Dealing with entity references off the main thread===

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything. Failing that, we could bake the data into the shared library so that it's available as static data on any thread.

===Lack of actual speculation===

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::XmlStreamParser: mozilla::XmlMainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

==Parsing XML that's not Web content-like==

We use expat for 1) XHR, 2) XML Web content, 3) Firefox UI files using the prototype parser and 4) for XSLT programs. Moving the last two off-the-main-thread may not be worthwhile.

==Fragment parsing==

On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths.

==XSLT and XHR==

The document that is given as input to an XSLT program and the document loaded via XHR are currently built by nsXMLContentSink. In the new world, they'd use the tree op mechanism instead like other things that currently use nsXMLContentSink.

==Showing a common interface to nsDocument==

nsIParser is pointlessly crufty and COMtaminated. There should be a new non-XPCOM abstract class that shows the commonality of XML and HTML parsing to nsDocument but no cruft. The new interface should look something like this:

class mozilla::parser::AParser {
virtual void setCharsetAndSource(mozilla::Encoding* aEncoding, uint32_t aSource) = 0;
virtual nsIStreamListener* GetStreamListener() = 0;
virtual void UnblockParser() = 0;
virtual void Start(nsIRequestObserver* aObserver) = 0; // Replaces Parse()
virtual void Terminate() = 0;
// possibly document.write and script execution stuff that'd be no-op in the XML case
};

Both mozilla::XmlParser and nsHtml5Parser would inherit from this abstract class.

Oxidation

2020-02-17T14:32:51Z

Hsivonen: Based in Phabricator, the expat rewrite seems to be in progress rather than just planned

'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox.

Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.

This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.

= Guidelines =

The goal of this section is to provide some high-level guidelines about when Rust should be used.

In summary, Rust should be used in the following situations.
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.
* For existing components it's more complicated!

The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.

== Rust Strengths ==

Rust has the following strengths.
* Memory safety, which prevents crashes and security vulnerabilities.
* Thread safety, which enables improved performance via parallelism.
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.
* Pleasant to use, particularly once a moderate level of experience has been reached.
* A great community.

== Rust Weaknesses ==

One major issue with Rust relates to personnel.
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.
* Rust's learning curve is steep at the start, which can be intimidating.

There are also technical challenges.
* Compilation is slow.
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].

See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.

== Recommendations ==

Therefore, Rust is most suitable in the following situations.
* For components that are relatively standalone, with small and simple APIs.
** This minimizes the C++/Rust boundary layer issues.
** Infrastructure tools that are standalone programs are ideal.
** Note that it's good software engineering practice to write loosely-coupled components anyway.
* For components that process untrusted input, e.g. parsers.
** Rust's memory safety is a big help here.
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.
* For components where parallelism can provide big performance wins.
* For components where Servo has demonstrated success.

In terms of where to keep Rust crates, there are three options.
* Put the crate in mozilla-central or in Servo's repository.
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.
** This makes sense for pre-existing third-party crates that we choose to import.
** Otherwise, this option is not recommended, because vendoring is something of a hassle.

In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.

= Documentation and assistance =

== Rust in general ==

* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.

== Rust in Firefox ==

* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.
** Alexis Beingessner (:gankro)
** Josh Bowman-Matthews (:jdm)
** Emilio Cobos Alvarez (:emilio)
** Manish Goregaokar (:manishearth)
** Nika Layzell (:mystor)
** Cameron McCormack (:heycam)

== FAQ ==

'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central? 

'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.

'''Q:''' Do we support building standalone Rust programs? 

'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.

'''Q:''' How are in-tree Rust crates tested? 

'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.

= Rust Components =

== Within Firefox ==

=== Shipped ===

* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.

=== In progress ===

* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.
* Audio remoting for Windows: {{bug|1432303}}
* Audio remoting for Mac OS: {{bug|1425788}}
* SDP parsing in WebRTC: {{bug|1365792}}
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)
* Background Update Agent for Windows: {{bug|1343669}}
* Replace the XML parser: {{bug|1611289}}
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.

=== Proposed ===

* Parallel layout
** '''Why Rust?''' Existing code from Servo, parallel performance.
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}
* Gamepad code: {{bug|1286699}}
* Replace the telemetry module(?)
** '''Why Rust?''' The existing C++ code has a history of threading problems.
* Replace DOM serializers (XML, HTML for Save As.., plain text)
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.
* Image decoders?
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.
* Expose Rust API to JS Debugger: {{bug|1263317}}
* Generate Rust bindings for IPDL actors ({{bug|1379739}})
* WebM demuxer: {{bug|1267492}}
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.
* Crash reporter
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.

== Outside Firefox ==

=== Completed ===

* Testing
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.
* Build system, etc.
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.
* Application Services, server-side
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.
*** '''Why Rust?''' Concise code with the memory efficiency of C.
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.
* Application Services, client-side
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.

=== In Progress ===

* IPDL Parser: {{bug|1316754}}
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.

= Blockers and obstacles =

This section lists areas where Rust integration could be improved.
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}
* Compile speed and memory usage
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.
* Bindings/interop
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.
** No IPDL binding generator ({{bug|1379739}})
** No WebIDL binding generator for DOM components (Servo must have something here?)
* Remaining minor crash report issues {{bug|1348896}}
* IDE/symbol lookup support?
* Code coverage?
* Profiling improvements? Especially for parallel code
* Test integration?

= Meetings =

* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]

Oxidation

2020-02-17T14:31:19Z

Hsivonen: Firefox 73 shipped

'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox.

Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.

This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.

= Guidelines =

The goal of this section is to provide some high-level guidelines about when Rust should be used.

In summary, Rust should be used in the following situations.
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.
* For existing components it's more complicated!

The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.

== Rust Strengths ==

Rust has the following strengths.
* Memory safety, which prevents crashes and security vulnerabilities.
* Thread safety, which enables improved performance via parallelism.
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.
* Pleasant to use, particularly once a moderate level of experience has been reached.
* A great community.

== Rust Weaknesses ==

One major issue with Rust relates to personnel.
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.
* Rust's learning curve is steep at the start, which can be intimidating.

There are also technical challenges.
* Compilation is slow.
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].

See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.

== Recommendations ==

Therefore, Rust is most suitable in the following situations.
* For components that are relatively standalone, with small and simple APIs.
** This minimizes the C++/Rust boundary layer issues.
** Infrastructure tools that are standalone programs are ideal.
** Note that it's good software engineering practice to write loosely-coupled components anyway.
* For components that process untrusted input, e.g. parsers.
** Rust's memory safety is a big help here.
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.
* For components where parallelism can provide big performance wins.
* For components where Servo has demonstrated success.

In terms of where to keep Rust crates, there are three options.
* Put the crate in mozilla-central or in Servo's repository.
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.
** This makes sense for pre-existing third-party crates that we choose to import.
** Otherwise, this option is not recommended, because vendoring is something of a hassle.

In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.

= Documentation and assistance =

== Rust in general ==

* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.

== Rust in Firefox ==

* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.
** Alexis Beingessner (:gankro)
** Josh Bowman-Matthews (:jdm)
** Emilio Cobos Alvarez (:emilio)
** Manish Goregaokar (:manishearth)
** Nika Layzell (:mystor)
** Cameron McCormack (:heycam)

== FAQ ==

'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central? 

'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.

'''Q:''' Do we support building standalone Rust programs? 

'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.

'''Q:''' How are in-tree Rust crates tested? 

'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.

= Rust Components =

== Within Firefox ==

=== Shipped ===

* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.

=== In progress ===

* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.
* Audio remoting for Windows: {{bug|1432303}}
* Audio remoting for Mac OS: {{bug|1425788}}
* SDP parsing in WebRTC: {{bug|1365792}}
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)
* Background Update Agent for Windows: {{bug|1343669}}

=== Proposed ===

* Parallel layout
** '''Why Rust?''' Existing code from Servo, parallel performance.
* Replace the XML parser: {{bug|1611289}}
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}
* Gamepad code: {{bug|1286699}}
* Replace the telemetry module(?)
** '''Why Rust?''' The existing C++ code has a history of threading problems.
* Replace DOM serializers (XML, HTML for Save As.., plain text)
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.
* Image decoders?
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.
* Expose Rust API to JS Debugger: {{bug|1263317}}
* Generate Rust bindings for IPDL actors ({{bug|1379739}})
* WebM demuxer: {{bug|1267492}}
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.
* Crash reporter
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.

== Outside Firefox ==

=== Completed ===

* Testing
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.
* Build system, etc.
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.
* Application Services, server-side
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.
*** '''Why Rust?''' Concise code with the memory efficiency of C.
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.
* Application Services, client-side
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.

=== In Progress ===

* IPDL Parser: {{bug|1316754}}
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.

= Blockers and obstacles =

This section lists areas where Rust integration could be improved.
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}
* Compile speed and memory usage
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.
* Bindings/interop
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.
** No IPDL binding generator ({{bug|1379739}})
** No WebIDL binding generator for DOM components (Servo must have something here?)
* Remaining minor crash report issues {{bug|1348896}}
* IDE/symbol lookup support?
* Code coverage?
* Profiling improvements? Especially for parallel code
* Test integration?

= Meetings =

* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]

Oxidation

2020-01-27T12:34:53Z

Hsivonen: Move chardetng to the shipped list since it's riding the trains

'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox.

Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.

This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.

= Guidelines =

The goal of this section is to provide some high-level guidelines about when Rust should be used.

In summary, Rust should be used in the following situations.
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.
* For existing components it's more complicated!

The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.

== Rust Strengths ==

Rust has the following strengths.
* Memory safety, which prevents crashes and security vulnerabilities.
* Thread safety, which enables improved performance via parallelism.
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.
* Pleasant to use, particularly once a moderate level of experience has been reached.
* A great community.

== Rust Weaknesses ==

One major issue with Rust relates to personnel.
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.
* Rust's learning curve is steep at the start, which can be intimidating.

There are also technical challenges.
* Compilation is slow.
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].

See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.

== Recommendations ==

Therefore, Rust is most suitable in the following situations.
* For components that are relatively standalone, with small and simple APIs.
** This minimizes the C++/Rust boundary layer issues.
** Infrastructure tools that are standalone programs are ideal.
** Note that it's good software engineering practice to write loosely-coupled components anyway.
* For components that process untrusted input, e.g. parsers.
** Rust's memory safety is a big help here.
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.
* For components where parallelism can provide big performance wins.
* For components where Servo has demonstrated success.

In terms of where to keep Rust crates, there are three options.
* Put the crate in mozilla-central or in Servo's repository.
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.
** This makes sense for pre-existing third-party crates that we choose to import.
** Otherwise, this option is not recommended, because vendoring is something of a hassle.

In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.

= Documentation and assistance =

== Rust in general ==

* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.

== Rust in Firefox ==

* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.
** Alexis Beingessner (:gankro)
** Josh Bowman-Matthews (:jdm)
** Emilio Cobos Alvarez (:emilio)
** Manish Goregaokar (:manishearth)
** Nika Layzell (:mystor)
** Cameron McCormack (:heycam)

== FAQ ==

'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central? 

'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.

'''Q:''' Do we support building standalone Rust programs? 

'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.

'''Q:''' How are in-tree Rust crates tested? 

'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.

= Rust Components =

== Within Firefox ==

=== Shipped ===

* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.
* Encoding detector: {{bug|1551276}} (riding the Firefox 73 train)
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.

=== In progress ===

* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.
* Audio remoting for Windows: {{bug|1432303}}
* Audio remoting for Mac OS: {{bug|1425788}}
* SDP parsing in WebRTC: {{bug|1365792}}
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)
* Background Update Agent for Windows: {{bug|1343669}}

=== Proposed ===

* Parallel layout
** '''Why Rust?''' Existing code from Servo, parallel performance.
* Replace the XML parser
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}
* Gamepad code: {{bug|1286699}}
* Replace the telemetry module(?)
** '''Why Rust?''' The existing C++ code has a history of threading problems.
* Replace DOM serializers (XML, HTML for Save As.., plain text)
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.
* Image decoders?
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.
* Expose Rust API to JS Debugger: {{bug|1263317}}
* Generate Rust bindings for IPDL actors ({{bug|1379739}})
* WebM demuxer: {{bug|1267492}}
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.
* Crash reporter
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.

== Outside Firefox ==

=== Completed ===

* Testing
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.
* Build system, etc.
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.
* Application Services, server-side
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.
*** '''Why Rust?''' Concise code with the memory efficiency of C.
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.
* Application Services, client-side
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.

=== In Progress ===

* IPDL Parser: {{bug|1316754}}
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.

= Blockers and obstacles =

This section lists areas where Rust integration could be improved.
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}
* Compile speed and memory usage
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.
* Bindings/interop
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.
** No IPDL binding generator ({{bug|1379739}})
** No WebIDL binding generator for DOM components (Servo must have something here?)
* Remaining minor crash report issues {{bug|1348896}}
* IDE/symbol lookup support?
* Code coverage?
* Profiling improvements? Especially for parallel code
* Test integration?

= Meetings =

* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]

Oxidation

2019-12-07T14:31:40Z

Hsivonen: Mention rayon in the context of encoding detection

'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox.

Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.

This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.

= Guidelines =

The goal of this section is to provide some high-level guidelines about when Rust should be used.

In summary, Rust should be used in the following situations.
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.
* For existing components it's more complicated!

The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.

== Rust Strengths ==

Rust has the following strengths.
* Memory safety, which prevents crashes and security vulnerabilities.
* Thread safety, which enables improved performance via parallelism.
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.
* Pleasant to use, particularly once a moderate level of experience has been reached.
* A great community.

== Rust Weaknesses ==

One major issue with Rust relates to personnel.
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.
* Rust's learning curve is steep at the start, which can be intimidating.

There are also technical challenges.
* Compilation is slow.
* Crossing the C++/Rust boundary can be difficult.

See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.

== Recommendations ==

Therefore, Rust is most suitable in the following situations.
* For components that are relatively standalone, with small and simple APIs.
** This minimizes the C++/Rust boundary layer issues.
** Infrastructure tools that are standalone programs are ideal.
** Note that it's good software engineering practice to write loosely-coupled components anyway.
* For components that process untrusted input, e.g. parsers.
** Rust's memory safety is a big help here.
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.
* For components where parallelism can provide big performance wins.
* For components where Servo has demonstrated success.

In terms of where to keep Rust crates, there are three options.
* Put the crate in mozilla-central or in Servo's repository.
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.
** This makes sense for pre-existing third-party crates that we choose to import.
** Otherwise, this option is not recommended, because vendoring is something of a hassle.

In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.

= Documentation and assistance =

== Rust in general ==

* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.

== Rust in Firefox ==

* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.
** Alexis Beingessner (:gankro)
** Josh Bowman-Matthews (:jdm)
** Emilio Cobos Alvarez (:emilio)
** Manish Goregaokar (:manishearth)
** Nika Layzell (:mystor)
** Cameron McCormack (:heycam)

== FAQ ==

'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central? 

'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.

'''Q:''' Do we support building standalone Rust programs? 

'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.

'''Q:''' How are in-tree Rust crates tested? 

'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.

= Rust Components =

== Within Firefox ==

=== Shipped ===

* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.

=== In progress ===

* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.
* Audio remoting for Windows: {{bug|1432303}}
* Audio remoting for Mac OS: {{bug|1425788}}
* SDP parsing in WebRTC: {{bug|1365792}}
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)
* Background Update Agent for Windows: {{bug|1343669}}
* Encoding detector: {{bug|1551276}}
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.

=== Proposed ===

* Parallel layout
** '''Why Rust?''' Existing code from Servo, parallel performance.
* Replace the XML parser
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}
* Gamepad code: {{bug|1286699}}
* Replace the telemetry module(?)
** '''Why Rust?''' The existing C++ code has a history of threading problems.
* Replace DOM serializers (XML, HTML for Save As.., plain text)
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.
* Image decoders?
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.
* Expose Rust API to JS Debugger: {{bug|1263317}}
* Generate Rust bindings for IPDL actors ({{bug|1379739}})
* WebM demuxer: {{bug|1267492}}
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.
* Crash reporter
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.

== Outside Firefox ==

=== Completed ===

* Testing
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.
* Build system, etc.
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.
* Application Services, server-side
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.
*** '''Why Rust?''' Concise code with the memory efficiency of C.
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.
* Application Services, client-side
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.

=== In Progress ===

* IPDL Parser: {{bug|1316754}}
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.

= Blockers and obstacles =

This section lists areas where Rust integration could be improved.
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}
* Compile speed and memory usage
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.
* Bindings/interop
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.
** No IPDL binding generator ({{bug|1379739}})
** No WebIDL binding generator for DOM components (Servo must have something here?)
* Remaining minor crash report issues {{bug|1348896}}
* IDE/symbol lookup support?
* Code coverage?
* Profiling improvements? Especially for parallel code
* Test integration?

= Meetings =

* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]

Oxidation

2019-12-07T14:29:50Z

Hsivonen: Mention encoding detectors

'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox.

Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.

This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.

= Guidelines =

The goal of this section is to provide some high-level guidelines about when Rust should be used.

In summary, Rust should be used in the following situations.
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.
* For existing components it's more complicated!

The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.

== Rust Strengths ==

Rust has the following strengths.
* Memory safety, which prevents crashes and security vulnerabilities.
* Thread safety, which enables improved performance via parallelism.
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.
* Pleasant to use, particularly once a moderate level of experience has been reached.
* A great community.

== Rust Weaknesses ==

One major issue with Rust relates to personnel.
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.
* Rust's learning curve is steep at the start, which can be intimidating.

There are also technical challenges.
* Compilation is slow.
* Crossing the C++/Rust boundary can be difficult.

See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.

== Recommendations ==

Therefore, Rust is most suitable in the following situations.
* For components that are relatively standalone, with small and simple APIs.
** This minimizes the C++/Rust boundary layer issues.
** Infrastructure tools that are standalone programs are ideal.
** Note that it's good software engineering practice to write loosely-coupled components anyway.
* For components that process untrusted input, e.g. parsers.
** Rust's memory safety is a big help here.
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.
* For components where parallelism can provide big performance wins.
* For components where Servo has demonstrated success.

In terms of where to keep Rust crates, there are three options.
* Put the crate in mozilla-central or in Servo's repository.
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.
** This makes sense for pre-existing third-party crates that we choose to import.
** Otherwise, this option is not recommended, because vendoring is something of a hassle.

In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.

= Documentation and assistance =

== Rust in general ==

* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.

== Rust in Firefox ==

* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.
** Alexis Beingessner (:gankro)
** Josh Bowman-Matthews (:jdm)
** Emilio Cobos Alvarez (:emilio)
** Manish Goregaokar (:manishearth)
** Nika Layzell (:mystor)
** Cameron McCormack (:heycam)

== FAQ ==

'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central? 

'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.

'''Q:''' Do we support building standalone Rust programs? 

'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.

'''Q:''' How are in-tree Rust crates tested? 

'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.

= Rust Components =

== Within Firefox ==

=== Shipped ===

* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.

=== In progress ===

* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.
* Audio remoting for Windows: {{bug|1432303}}
* Audio remoting for Mac OS: {{bug|1425788}}
* SDP parsing in WebRTC: {{bug|1365792}}
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)
* Background Update Agent for Windows: {{bug|1343669}}
* Encoding detector: {{bug|1551276}}
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.

=== Proposed ===

* Parallel layout
** '''Why Rust?''' Existing code from Servo, parallel performance.
* Replace the XML parser
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}
* Gamepad code: {{bug|1286699}}
* Replace the telemetry module(?)
** '''Why Rust?''' The existing C++ code has a history of threading problems.
* Replace DOM serializers (XML, HTML for Save As.., plain text)
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.
* Image decoders?
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.
* Expose Rust API to JS Debugger: {{bug|1263317}}
* Generate Rust bindings for IPDL actors ({{bug|1379739}})
* WebM demuxer: {{bug|1267492}}
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.
* Crash reporter
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.

== Outside Firefox ==

=== Completed ===

* Testing
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.
* Build system, etc.
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.
* Application Services, server-side
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.
*** '''Why Rust?''' Concise code with the memory efficiency of C.
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.
* Application Services, client-side
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.

=== In Progress ===

* IPDL Parser: {{bug|1316754}}
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.

= Blockers and obstacles =

This section lists areas where Rust integration could be improved.
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}
* Compile speed and memory usage
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.
* Bindings/interop
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.
** No IPDL binding generator ({{bug|1379739}})
** No WebIDL binding generator for DOM components (Servo must have something here?)
* Remaining minor crash report issues {{bug|1348896}}
* IDE/symbol lookup support?
* Code coverage?
* Profiling improvements? Especially for parallel code
* Test integration?

= Meetings =

* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]

Standards

2018-12-04T15:46:02Z

Hsivonen: /* HTML Media Extensions Working Group */ Tweak Media Extensions participation wording

Welcome to Mozilla's standards participation page.

This is a directory of standards organizations and their working groups, listing who at Mozilla is working with each.

For a technology summary see the [[standards/technologies|technologies]] page, for Mozilla’s positions on particular specifications, see:
* https://mozilla.github.io/standards-positions/
Current discussions of Mozilla positions:
* https://github.com/mozilla/standards-positions/issues

The lists below are organized alphabetically by standards body and working group (if any), with Mozilla participants and specifications they edit/author/contribute to.

If you’re a Mozillian actively & directly participating in a standards body (working group email list, IRC, wiki, and/or f2f meetings), please add yourself to the specific standards body / working group if any), linking to your wiki User: page. If you’re working in multiple working groups or standards organizations, add yourself to each.

Thanks!

— [[User:Tantek|Tantek]]

= Web Standards Coordination =

== General Participation Guidelines ==
If you'd like to participate in some of these groups, or at least watch, learn, get up to speed, you can almost always do so by lurking on the public IRC channels and mailing lists that the groups use. Many (most?) standards mailing lists can often be overwhelming in quantity, depth so start with IRC as that's often lighter-weight and easier to watch for quick bits of info/knowledge.

* Follow the instructions on the [[IRC|IRC wiki page]] to:
** Set yourself up with a nickname and connection to <code>irc.mozilla.org</code>.
* Add a connection to <code>irc.freenode.net</code> (also with '''[x] SSL''') where many standards discussions take place.
* Add another connection to <code>irc.w3.org</code> but specifically port 6665 (unprotected, no nickname registration).
* See each standards section below for which IRC channel(s) tend(s) to be used by folks working in each group.

== ECMA TC39 ==
* Till Schneidereit
* Lin Clark
* [[User:Ystartsev|Yulia Startsev]] co-chair

Specifications: ECMAScript 5, 5.1, 6, Harmony, etc.

== [https://ietf.org/ IETF] ==

=== ISOC Advisory Council ===
* [[User:AdamRoach|Adam Roach]] (:abr)
* Tim Terriberry (:derf)

=== [https://www.iab.org/about/iab-members/ Internet Architecture Board] (IAB) ===
* Joe Hildebrand
* Martin Thomson

=== [https://www.ietf.org/iesg/members.html Internet Engineering Steering Group] (IESG) ===
* [[User:AdamRoach|Adam Roach]] (Applications and Real-Time Area)
* Eric Rescorla (Security Area)

=== [https://datatracker.ietf.org/wg/calext/about/ CALEXT] (iCalendar) ===
* Philipp Kewisch

=== [https://datatracker.ietf.org/wg/dispatch/about/ DISPATCH] ===
* Martin Thomson
* Eric Rescorla
* [[User:AdamRoach|Adam Roach]]

=== [https://datatracker.ietf.org/wg/dnsop/about/ DNSOP] ===

* lshapiro (Larissa Shapiro)

=== [https://datatracker.ietf.org/wg/doh/about/ DNS over HTTPS (DoH)] ===
* Martin Thomson

=== [https://httpwg.github.io/ HTTPbis] ===
* Martin Thomson
* Dragana Damjanovic

=== [https://datatracker.ietf.org/wg/netvc/ NETVC] ===

* [[User:AdamRoach|Adam Roach]] (:abr) - WG Chair
* Timothy B. Terriberry (:derf)
* Jean-Marc Valin (:jmspeex)
* Nathan Egge

=== [https://datatracker.ietf.org/wg/codec/about/ CODEC] (Opus) ===
* Jean-Marc Valin (:jmspeex)
* Tim Terriberry (:derf)

=== [https://quicwg.github.io/ QUIC] ===
* Martin Thomson
* Eric Rescorla

=== [https://datatracker.ietf.org/wg/rtcweb/about/ RTCWEB] / [https://datatracker.ietf.org/wg/mmusic/about/ MMUSIC] ===
* Randell Jesup
* Tim Terriberry
* [[User:AdamRoach|Adam Roach]] (:abr)
* Eric Rescorla (EKR)
* Martin Thomson
* Maire Reavy 

=== [https://datatracker.ietf.org/wg/stir/about/ STIR] ===

* Eric Rescorla

=== [https://datatracker.ietf.org/wg/tokbind/about/ TOKBIND] ===

* Eric Rescorla

=== [http://tlswg.github.io/ TLS] (SSL) ===

* Martin Thomson
* Eric Rescorla

=== [https://datatracker.ietf.org/wg/webpush/about/ WebPush] ===

* Martin Thomson

== Khronos ==
[http://www.khronos.org/webgl/ WebGL]
* Jeff Gilbert (:jgilbert)

== microformats ==
http://microformats.org/ and [http://microformats.org/wiki microformats wiki]
* irc://irc.freenode.net/microformats
Community participants:
* [[User:Tantek|Tantek Çelik]] (founder, admin)
* Michael Kaply
* ...

Specifications:
* [[hCard]] - implemented in Firefox DOM
* [[hCalendar]] - implemented in Firefox DOM
* ... and many others.

== OWF ==
http://openwebfoundation.org/
* [[User:Tantek|Tantek Çelik]] (elected board member)

Specifications:
* [http://openwebfoundation.org/legal/agreement/ Open Web Foundation Agreement] (OWFa) - used and recommended by [[Standards/license]]

== W3C ==
The [http://w3.org/ W3C] (World Wide Web Consortium) has Working Groups (WGs), Interest Groups (IGs), and Community Groups (CGs). See below for details and please add any/all of such groups here in alphabetical order by working group name.
* [[Standards/Participating in a W3C Working Group|Participating in a W3C Working Group]]
* [[Standards/W3C Charter Development and Review|W3C Charter Development and Review]]
* [https://www.w3.org/2000/09/dbwg/participants?org=35507&order=group Member-confidential (unfortunately) list of groups Mozilla participates in]

For the sake of focus and brevity, only W3C WGs are listed here inline, along with any complementary IGs or CGs that are paired with them.

For other W3C IGs or CGs not tied directly to an active WG, see:
* [[Standards/w3c-interest-community-groups]]

=== Advisory Board ===
[http://www.w3.org/wiki/AB W3C Advisory Board] (AB) drives W3C process improvements in:
==== Process Community Group ====
[https://www.w3.org/community/w3process/ W3C Process Community Group] publicly discusses ([https://www.w3.org/wiki/W3Process wiki], [https://github.com/w3c/w3process/ GitHub repo], [https://lists.w3.org/Archives/Public/public-w3process/ list]), proposes, and makes changes to the W3C Process. Delegated authority from the AB (some members of which overlap with the CG), which retains overall (dis)approval of W3C Process iterations before proposing to the AC.
* [[User:Tantek|Tantek Çelik]]

=== Advisory Committee ===
* [[User:Dbaron|David Baron]] - Advisory Committee (AC) representative
See [https://www.w3.org/Member/ACList Advisory Committee Representative Directory] for who else is an AC Rep from which companies.

=== Audio Working Group ===
* http://www.w3.org/2011/audio/
[https://www.w3.org/2000/09/dbwg/details?group=46884&public=1&order=org#_MozillaFoundation Participants]:
* Matthew Gregan
* Paul Adenot
* Ehsan Akhgari

=== Browser Testing and Tools Working Group ===
[https://www.w3.org/testing/browser/ Browser Testing and Tools Working Group homepage], [https://www.w3.org/2011/08/browser-testing-charter.html Charter], [mailto:public-browser-tools-testing@w3.org Mailing list], [https://lists.w3.org/Archives/Public/public-browser-tools-testing/ Mailing list archive]
* [[User:Ato|Andreas Tolfsen]]
* [[User:Dburns|David Burns]] (co-editor and chair)
* [[User:Jgraham|James Graham]]

Specifications:
* [http://w3c.github.io/webdriver/webdriver-spec.html WebDriver] - APIs for remote controlling web browsers
* (link?) APIs for use in debugging of web applications

=== CSS Working Group ===
* Looking for where we prioritize our CSS development? See: '''[[CSS#Priorities|CSS:Priorities]]'''
CSS (Cascading Style Sheets) Working Group (WG)
* home page: http://w3.org/Style/CSS/
* irc://irc.w3.org:6665/css
* email: http://lists.w3.org/Archives/Public/www-style/
Working group members related to Mozilla (also on w3c-css-wg)
* [[User:Dbaron|David Baron]]
* [[User:Brian|Brian Birtles]]
* [[User:Tantek|Tantek Çelik]]
* [[User:jensimmons|Jen Simmons]]
* Masayuki Nakano

Additional www-style list participants related to Mozilla (anyone is welcome to join)
* Robert O'Callahan
* [[User:Hsivonen|Henri Sivonen]]
* [[User:Bzbarsky|Boris Zbarsky]]
* [[User:Dholbert|Daniel Holbert]]
* ...

Specifications: [[CSS21]], [[CSS3]]

See also: [[CSS]] on this wiki.

=== Geolocation Working Group ===
Geolocation Working Group (GEO) http://www.w3.org/2008/geolocation/
* ...

=== HTML Media Extensions Working Group ===
* [[User:Hsivonen|Henri Sivonen]] (Previously provided feedback on specs within scope for this WG but not actively participating in present discussion)

=== HTML Speech Incubator Group ===
* David Bolter
* Olli Pettay

=== Indie UI Events ===
http://www.w3.org/2011/11/indie-ui-charter
* David Bolter (monitoring)

=== Internationalization Activity ===
http://w3.org/International/ (i18n)
* ...

=== Media Fragments Working Group ===
* Chris Double

=== Pointer Events Working Group ===
* http://www.w3.org/2012/pointerevents/
Participants:
* Olli Pettay
* Matt Brubeck

=== Protocols and Formats Working Group ===
(Web Accessibility) Protocols and Formats Working Group (PF WG)
* David Bolter

=== Second Screen Working Group ===
* http://www.w3.org/2014/secondscreen/
[https://www.w3.org/2000/09/dbwg/details?group=74168&public=1&order=org#_MozillaFoundation Participants]:
* Bradford Lassey
* Shih-Chiang Chien

=== SVG Working Group ===
SVG (Scalable Vector Graphics) Working Group
http://w3.org/SVG/
* Cameron McCormack (co-chair)
* [[User:Brian|Brian Birtles]]
* Jonathan Watt

Specifications: SVG 1.1, SVG 2.0

=== Tracking Protection Working Group ===
http://www.w3.org/2011/tracking-protection/
* Heather West

=== Technical Architecture Group ===
W3C [http://www.w3.org/2001/tag/ TAG]
* [[User:Dbaron|David Baron]]

=== Web Applications Security Working Group ===
* Eric Rescorla
* Daniel Veditz
* Tanvi Vyas
* Frederik Braun

Specifications: CSP, HSTS Priming, SRI, CORS (jointly with WebApps WG)

=== [https://www.w3.org/wasm/ Web Assembly Working Group] ===
WASM:
* [https://www.w3.org/2017/08/wasm-charter charter 2017-08-03 … 2018-07-31]
* [https://www.w3.org/2000/09/dbwg/details?group=101196&order=org&public=1 members]

==== WebAssembly Community Group ====
https://www.w3.org/community/webassembly/
* Luke Wagner
* Dan Gohman
* Alon Zakai
* Benjamin Bouvier
* Lin Clark
* Till Schneidereit

=== Web Cryptography Working Group ===
[http://www.w3.org/2012/webcrypto/ Web Cryptography Working Group]
* [[User:Ddahl|David Dahl]]
* Arun Ranganathan
* Eric Rescorla (EKR)

=== Web Events Working Group ===
* Matt Brubeck
* Olli Pettay

Specifications: Touch Events

Formerly: Touch Events Community Group

=== WebFonts Working Group ===
* Jonathan Kew (editor)
* John Daggett

=== Web Hypertext Application Technology Community Group ===
Directly related to [[#WHATWG]].
* [[User:Dbaron|David Baron]]
* [[User:Tantek|Tantek Çelik]]
* Cameron McCormack
See also the [http://www.w3.org/community/whatwg/participants complete list of participants].

Specifications: HTML living standard as developed by the WHATWG.

=== Web Payments Task Force ===
[http://www.w3.org/wiki/Payments_Task_Force http://www.w3.org/wiki/Payments_Task_Force]

* Kumar McMillan
* [http://www.w3.org/wiki/2013_Web_Payment_Task_Force_Participants Full list]

=== Web Performance Working Group ===

https://www.w3.org/webperf/

* Cameron McCormack
* Panos Astithas

Specifications: Timing control for script-based animations (requestAnimationFrame)

=== Web Platform Working Group ===
* Karl Dubost
* [[User:Marcosc|Marcos Caceres]]
* Martin Thomson
* Olli Pettay
* [[User:Tantek|Tantek Çelik]]
Primary work area: https://github.com/w3c/WebPlatformWG

Related incubator group: [https://www.w3.org/community/wicg/ Web Platform Incubator Community Group]

=== WebRTC Working Group ===
[[WebRTC]] (Web Real Time Communications) Working Group
* Maire Reavy
* Eric Rescorla (EKR)
* Tim Terriberry
* [[User:AdamRoach|Adam Roach]] (:abr)
* Randell Jesup (:jesup)

Specifications: Media capture & [http://www.w3.org/2011/04/webrtc-charter.html streaming APIs]

Specifications: Media Capture Stream with Worker Extensions [https://w3c.github.io/mediacapture-worker/ mediacapture-worker APIs]

== WHATWG ==
Web Hypertext Application Technologies Working Group - http://whatwg.org
* [[User:Dbaron|David Baron]]
* [[User:Tantek|Tantek Çelik]]
* [[User:Hsivonen|Henri Sivonen]]
* [[User:Annevk|Anne van Kesteren]]
* [[User:Marcosc|Marcos Caceres]] (:marcosc)

Web Editing specification - http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html
* [[User:Ehsan|Ehsan Akhgari]]

= other =

== Alliance for Open Media ==
The [http://aomedia.org/ Alliance for Open Media] develops next-generation media formats, codecs, and technologies. See also [[#NETVC]].
* Timothy B. Terriberry (:derf)

== CA/Browser Forum ==
The [http://cabforum.org/ CA/Browser Forum] produces standards in the area of best practice and validation for certificate authorities.
* Kathleen Wilson

== CalConnect ==
Mozilla is a member of [http://www.calconnect.org/ CalConnect], The Calendaring and Scheduling Consortium, which is not actually affiliated w/ IETF or W3C but in practice drives development and interoperability testing of IETF specs:
* RFC 5545 iCalendar (obsoletes RFC 2445).
* RFC 4791 CalDAV Access protocol
See their [http://www.calconnect.org/CD1104_Calendaring_Standards.shtml Index to Calendaring and Scheduling Standards] for other specific standards that CalConnect is involved with.

== OASIS ==
* No current Mozilla point of contact

== XMPP ==
Mozilla is not formally associated with the XSF but has representation indirectly. http://xmpp.org/
* no direct involvement by any current Mozillian

== C++ ==

C++ is standardized by [http://www.open-std.org/jtc1/sc22/wg21/ ISO/IEC JTC1/SC22/WG21] (informally, the "C++ Standards Committee"). All proposals are publically available [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/ here].

[https://mozillians.org/en-US/u/bballo/ Botond Ballo] is a member of Canada's delegation to the Committee, and has been attending meetings regularly since September 2013. If you have any feedback about any existing proposal, or would like to explore the idea of putting forth a new proposal, please post to dev-platform and cc Botond.

== Orgless specs ==
* [[APNG_Specification]]
** fork: [https://gist.github.com/SoniEx2/c679e771d506210378a5 MPNGPNG - Mutli-PNG PNG spec]

= Emeritus =
{{main|Standards/emeritus}}
See: [[Standards/emeritus]] for lists of former Mozillians who worked on standards, and former standards groups or organizations.

= subpages of {{FULLPAGENAME}}=
{{Special:PrefixIndex/{{FULLPAGENAME}}/}}

= See Also =
* [[CSS]]
* [[DOM]]
* [[Events]] - which include web standards-related events.
* [[SEO/Standards]] - how to use standards to improve/optimize search results
* [[Standards/license]] - what license Mozilla prefers for standards specifications
* https://platform-status.mozilla.org/

Standards

2018-12-04T15:43:02Z

Hsivonen: /* HTML Media Extensions Working Group */ Mentioning that I'm not actively participating in the Media Extensions WG

Welcome to Mozilla's standards participation page.

This is a directory of standards organizations and their working groups, listing who at Mozilla is working with each.

For a technology summary see the [[standards/technologies|technologies]] page, for Mozilla’s positions on particular specifications, see:
* https://mozilla.github.io/standards-positions/
Current discussions of Mozilla positions:
* https://github.com/mozilla/standards-positions/issues

The lists below are organized alphabetically by standards body and working group (if any), with Mozilla participants and specifications they edit/author/contribute to.

If you’re a Mozillian actively & directly participating in a standards body (working group email list, IRC, wiki, and/or f2f meetings), please add yourself to the specific standards body / working group if any), linking to your wiki User: page. If you’re working in multiple working groups or standards organizations, add yourself to each.

Thanks!

— [[User:Tantek|Tantek]]

= Web Standards Coordination =

== General Participation Guidelines ==
If you'd like to participate in some of these groups, or at least watch, learn, get up to speed, you can almost always do so by lurking on the public IRC channels and mailing lists that the groups use. Many (most?) standards mailing lists can often be overwhelming in quantity, depth so start with IRC as that's often lighter-weight and easier to watch for quick bits of info/knowledge.

* Follow the instructions on the [[IRC|IRC wiki page]] to:
** Set yourself up with a nickname and connection to <code>irc.mozilla.org</code>.
* Add a connection to <code>irc.freenode.net</code> (also with '''[x] SSL''') where many standards discussions take place.
* Add another connection to <code>irc.w3.org</code> but specifically port 6665 (unprotected, no nickname registration).
* See each standards section below for which IRC channel(s) tend(s) to be used by folks working in each group.

== ECMA TC39 ==
* Till Schneidereit
* Lin Clark
* [[User:Ystartsev|Yulia Startsev]] co-chair

Specifications: ECMAScript 5, 5.1, 6, Harmony, etc.

== [https://ietf.org/ IETF] ==

=== ISOC Advisory Council ===
* [[User:AdamRoach|Adam Roach]] (:abr)
* Tim Terriberry (:derf)

=== [https://www.iab.org/about/iab-members/ Internet Architecture Board] (IAB) ===
* Joe Hildebrand
* Martin Thomson

=== [https://www.ietf.org/iesg/members.html Internet Engineering Steering Group] (IESG) ===
* [[User:AdamRoach|Adam Roach]] (Applications and Real-Time Area)
* Eric Rescorla (Security Area)

=== [https://datatracker.ietf.org/wg/calext/about/ CALEXT] (iCalendar) ===
* Philipp Kewisch

=== [https://datatracker.ietf.org/wg/dispatch/about/ DISPATCH] ===
* Martin Thomson
* Eric Rescorla
* [[User:AdamRoach|Adam Roach]]

=== [https://datatracker.ietf.org/wg/dnsop/about/ DNSOP] ===

* lshapiro (Larissa Shapiro)

=== [https://datatracker.ietf.org/wg/doh/about/ DNS over HTTPS (DoH)] ===
* Martin Thomson

=== [https://httpwg.github.io/ HTTPbis] ===
* Martin Thomson
* Dragana Damjanovic

=== [https://datatracker.ietf.org/wg/netvc/ NETVC] ===

* [[User:AdamRoach|Adam Roach]] (:abr) - WG Chair
* Timothy B. Terriberry (:derf)
* Jean-Marc Valin (:jmspeex)
* Nathan Egge

=== [https://datatracker.ietf.org/wg/codec/about/ CODEC] (Opus) ===
* Jean-Marc Valin (:jmspeex)
* Tim Terriberry (:derf)

=== [https://quicwg.github.io/ QUIC] ===
* Martin Thomson
* Eric Rescorla

=== [https://datatracker.ietf.org/wg/rtcweb/about/ RTCWEB] / [https://datatracker.ietf.org/wg/mmusic/about/ MMUSIC] ===
* Randell Jesup
* Tim Terriberry
* [[User:AdamRoach|Adam Roach]] (:abr)
* Eric Rescorla (EKR)
* Martin Thomson
* Maire Reavy 

=== [https://datatracker.ietf.org/wg/stir/about/ STIR] ===

* Eric Rescorla

=== [https://datatracker.ietf.org/wg/tokbind/about/ TOKBIND] ===

* Eric Rescorla

=== [http://tlswg.github.io/ TLS] (SSL) ===

* Martin Thomson
* Eric Rescorla

=== [https://datatracker.ietf.org/wg/webpush/about/ WebPush] ===

* Martin Thomson

== Khronos ==
[http://www.khronos.org/webgl/ WebGL]
* Jeff Gilbert (:jgilbert)

== microformats ==
http://microformats.org/ and [http://microformats.org/wiki microformats wiki]
* irc://irc.freenode.net/microformats
Community participants:
* [[User:Tantek|Tantek Çelik]] (founder, admin)
* Michael Kaply
* ...

Specifications:
* [[hCard]] - implemented in Firefox DOM
* [[hCalendar]] - implemented in Firefox DOM
* ... and many others.

== OWF ==
http://openwebfoundation.org/
* [[User:Tantek|Tantek Çelik]] (elected board member)

Specifications:
* [http://openwebfoundation.org/legal/agreement/ Open Web Foundation Agreement] (OWFa) - used and recommended by [[Standards/license]]

== W3C ==
The [http://w3.org/ W3C] (World Wide Web Consortium) has Working Groups (WGs), Interest Groups (IGs), and Community Groups (CGs). See below for details and please add any/all of such groups here in alphabetical order by working group name.
* [[Standards/Participating in a W3C Working Group|Participating in a W3C Working Group]]
* [[Standards/W3C Charter Development and Review|W3C Charter Development and Review]]
* [https://www.w3.org/2000/09/dbwg/participants?org=35507&order=group Member-confidential (unfortunately) list of groups Mozilla participates in]

For the sake of focus and brevity, only W3C WGs are listed here inline, along with any complementary IGs or CGs that are paired with them.

For other W3C IGs or CGs not tied directly to an active WG, see:
* [[Standards/w3c-interest-community-groups]]

=== Advisory Board ===
[http://www.w3.org/wiki/AB W3C Advisory Board] (AB) drives W3C process improvements in:
==== Process Community Group ====
[https://www.w3.org/community/w3process/ W3C Process Community Group] publicly discusses ([https://www.w3.org/wiki/W3Process wiki], [https://github.com/w3c/w3process/ GitHub repo], [https://lists.w3.org/Archives/Public/public-w3process/ list]), proposes, and makes changes to the W3C Process. Delegated authority from the AB (some members of which overlap with the CG), which retains overall (dis)approval of W3C Process iterations before proposing to the AC.
* [[User:Tantek|Tantek Çelik]]

=== Advisory Committee ===
* [[User:Dbaron|David Baron]] - Advisory Committee (AC) representative
See [https://www.w3.org/Member/ACList Advisory Committee Representative Directory] for who else is an AC Rep from which companies.

=== Audio Working Group ===
* http://www.w3.org/2011/audio/
[https://www.w3.org/2000/09/dbwg/details?group=46884&public=1&order=org#_MozillaFoundation Participants]:
* Matthew Gregan
* Paul Adenot
* Ehsan Akhgari

=== Browser Testing and Tools Working Group ===
[https://www.w3.org/testing/browser/ Browser Testing and Tools Working Group homepage], [https://www.w3.org/2011/08/browser-testing-charter.html Charter], [mailto:public-browser-tools-testing@w3.org Mailing list], [https://lists.w3.org/Archives/Public/public-browser-tools-testing/ Mailing list archive]
* [[User:Ato|Andreas Tolfsen]]
* [[User:Dburns|David Burns]] (co-editor and chair)
* [[User:Jgraham|James Graham]]

Specifications:
* [http://w3c.github.io/webdriver/webdriver-spec.html WebDriver] - APIs for remote controlling web browsers
* (link?) APIs for use in debugging of web applications

=== CSS Working Group ===
* Looking for where we prioritize our CSS development? See: '''[[CSS#Priorities|CSS:Priorities]]'''
CSS (Cascading Style Sheets) Working Group (WG)
* home page: http://w3.org/Style/CSS/
* irc://irc.w3.org:6665/css
* email: http://lists.w3.org/Archives/Public/www-style/
Working group members related to Mozilla (also on w3c-css-wg)
* [[User:Dbaron|David Baron]]
* [[User:Brian|Brian Birtles]]
* [[User:Tantek|Tantek Çelik]]
* [[User:jensimmons|Jen Simmons]]
* Masayuki Nakano

Additional www-style list participants related to Mozilla (anyone is welcome to join)
* Robert O'Callahan
* [[User:Hsivonen|Henri Sivonen]]
* [[User:Bzbarsky|Boris Zbarsky]]
* [[User:Dholbert|Daniel Holbert]]
* ...

Specifications: [[CSS21]], [[CSS3]]

See also: [[CSS]] on this wiki.

=== Geolocation Working Group ===
Geolocation Working Group (GEO) http://www.w3.org/2008/geolocation/
* ...

=== HTML Media Extensions Working Group ===
* [[User:Hsivonen|Henri Sivonen]] (Not actively participating in discussion)

=== HTML Speech Incubator Group ===
* David Bolter
* Olli Pettay

=== Indie UI Events ===
http://www.w3.org/2011/11/indie-ui-charter
* David Bolter (monitoring)

=== Internationalization Activity ===
http://w3.org/International/ (i18n)
* ...

=== Media Fragments Working Group ===
* Chris Double

=== Pointer Events Working Group ===
* http://www.w3.org/2012/pointerevents/
Participants:
* Olli Pettay
* Matt Brubeck

=== Protocols and Formats Working Group ===
(Web Accessibility) Protocols and Formats Working Group (PF WG)
* David Bolter

=== Second Screen Working Group ===
* http://www.w3.org/2014/secondscreen/
[https://www.w3.org/2000/09/dbwg/details?group=74168&public=1&order=org#_MozillaFoundation Participants]:
* Bradford Lassey
* Shih-Chiang Chien

=== SVG Working Group ===
SVG (Scalable Vector Graphics) Working Group
http://w3.org/SVG/
* Cameron McCormack (co-chair)
* [[User:Brian|Brian Birtles]]
* Jonathan Watt

Specifications: SVG 1.1, SVG 2.0

=== Tracking Protection Working Group ===
http://www.w3.org/2011/tracking-protection/
* Heather West

=== Technical Architecture Group ===
W3C [http://www.w3.org/2001/tag/ TAG]
* [[User:Dbaron|David Baron]]

=== Web Applications Security Working Group ===
* Eric Rescorla
* Daniel Veditz
* Tanvi Vyas
* Frederik Braun

Specifications: CSP, HSTS Priming, SRI, CORS (jointly with WebApps WG)

=== [https://www.w3.org/wasm/ Web Assembly Working Group] ===
WASM:
* [https://www.w3.org/2017/08/wasm-charter charter 2017-08-03 … 2018-07-31]
* [https://www.w3.org/2000/09/dbwg/details?group=101196&order=org&public=1 members]

==== WebAssembly Community Group ====
https://www.w3.org/community/webassembly/
* Luke Wagner
* Dan Gohman
* Alon Zakai
* Benjamin Bouvier
* Lin Clark
* Till Schneidereit

=== Web Cryptography Working Group ===
[http://www.w3.org/2012/webcrypto/ Web Cryptography Working Group]
* [[User:Ddahl|David Dahl]]
* Arun Ranganathan
* Eric Rescorla (EKR)

=== Web Events Working Group ===
* Matt Brubeck
* Olli Pettay

Specifications: Touch Events

Formerly: Touch Events Community Group

=== WebFonts Working Group ===
* Jonathan Kew (editor)
* John Daggett

=== Web Hypertext Application Technology Community Group ===
Directly related to [[#WHATWG]].
* [[User:Dbaron|David Baron]]
* [[User:Tantek|Tantek Çelik]]
* Cameron McCormack
See also the [http://www.w3.org/community/whatwg/participants complete list of participants].

Specifications: HTML living standard as developed by the WHATWG.

=== Web Payments Task Force ===
[http://www.w3.org/wiki/Payments_Task_Force http://www.w3.org/wiki/Payments_Task_Force]

* Kumar McMillan
* [http://www.w3.org/wiki/2013_Web_Payment_Task_Force_Participants Full list]

=== Web Performance Working Group ===

https://www.w3.org/webperf/

* Cameron McCormack
* Panos Astithas

Specifications: Timing control for script-based animations (requestAnimationFrame)

=== Web Platform Working Group ===
* Karl Dubost
* [[User:Marcosc|Marcos Caceres]]
* Martin Thomson
* Olli Pettay
* [[User:Tantek|Tantek Çelik]]
Primary work area: https://github.com/w3c/WebPlatformWG

Related incubator group: [https://www.w3.org/community/wicg/ Web Platform Incubator Community Group]

=== WebRTC Working Group ===
[[WebRTC]] (Web Real Time Communications) Working Group
* Maire Reavy
* Eric Rescorla (EKR)
* Tim Terriberry
* [[User:AdamRoach|Adam Roach]] (:abr)
* Randell Jesup (:jesup)

Specifications: Media capture & [http://www.w3.org/2011/04/webrtc-charter.html streaming APIs]

Specifications: Media Capture Stream with Worker Extensions [https://w3c.github.io/mediacapture-worker/ mediacapture-worker APIs]

== WHATWG ==
Web Hypertext Application Technologies Working Group - http://whatwg.org
* [[User:Dbaron|David Baron]]
* [[User:Tantek|Tantek Çelik]]
* [[User:Hsivonen|Henri Sivonen]]
* [[User:Annevk|Anne van Kesteren]]
* [[User:Marcosc|Marcos Caceres]] (:marcosc)

Web Editing specification - http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html
* [[User:Ehsan|Ehsan Akhgari]]

= other =

== Alliance for Open Media ==
The [http://aomedia.org/ Alliance for Open Media] develops next-generation media formats, codecs, and technologies. See also [[#NETVC]].
* Timothy B. Terriberry (:derf)

== CA/Browser Forum ==
The [http://cabforum.org/ CA/Browser Forum] produces standards in the area of best practice and validation for certificate authorities.
* Kathleen Wilson

== CalConnect ==
Mozilla is a member of [http://www.calconnect.org/ CalConnect], The Calendaring and Scheduling Consortium, which is not actually affiliated w/ IETF or W3C but in practice drives development and interoperability testing of IETF specs:
* RFC 5545 iCalendar (obsoletes RFC 2445).
* RFC 4791 CalDAV Access protocol
See their [http://www.calconnect.org/CD1104_Calendaring_Standards.shtml Index to Calendaring and Scheduling Standards] for other specific standards that CalConnect is involved with.

== OASIS ==
* No current Mozilla point of contact

== XMPP ==
Mozilla is not formally associated with the XSF but has representation indirectly. http://xmpp.org/
* no direct involvement by any current Mozillian

== C++ ==

C++ is standardized by [http://www.open-std.org/jtc1/sc22/wg21/ ISO/IEC JTC1/SC22/WG21] (informally, the "C++ Standards Committee"). All proposals are publically available [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/ here].

[https://mozillians.org/en-US/u/bballo/ Botond Ballo] is a member of Canada's delegation to the Committee, and has been attending meetings regularly since September 2013. If you have any feedback about any existing proposal, or would like to explore the idea of putting forth a new proposal, please post to dev-platform and cc Botond.

== Orgless specs ==
* [[APNG_Specification]]
** fork: [https://gist.github.com/SoniEx2/c679e771d506210378a5 MPNGPNG - Mutli-PNG PNG spec]

= Emeritus =
{{main|Standards/emeritus}}
See: [[Standards/emeritus]] for lists of former Mozillians who worked on standards, and former standards groups or organizations.

= subpages of {{FULLPAGENAME}}=
{{Special:PrefixIndex/{{FULLPAGENAME}}/}}

= See Also =
* [[CSS]]
* [[DOM]]
* [[Events]] - which include web standards-related events.
* [[SEO/Standards]] - how to use standards to improve/optimize search results
* [[Standards/license]] - what license Mozilla prefers for standards specifications
* https://platform-status.mozilla.org/

GitHub

2018-03-08T14:03:48Z

Hsivonen: Fix formatting

This page is specifically about [https://github.com/mozilla the "mozilla" organization on github]. There are several other github organizations you may be interested in, cf. the incomplete list [[#other_github|below]].
<div id="contact">
{| class="wikitable"
|-
! [[File:Red_question_mark.png|144px|Send us an email!|link=]] Got a question?
|-
| Email {{emailentry|github-owners|mozilla.org|at=is}} 
Bugzilla [https://bugzilla.mozilla.org/enter_bug.cgi?comment=I%27ve%20read%20https%3A%2F%2Fwiki.mozilla.org%2FGithub%2C%20and%20need%20help%20with%20the%20following.%0D%0A%0D%0A&component=Github%3A%20Administration&form_name=enter_bug&product=mozilla.org& mozilla.org :: Github: Administration] 
irc #github on [[IRC|moznet]]
|}

== News ==
* As of June 20, 2016, all members [https://groups.google.com/forum/#!topic/mozilla.dev.platform/UmHOOh3qtiM must have 2FA enabled]. You have been notified if this impacts you.

== Recommendations and FAQ ==

=== Where should I ask additional questions? ===
* Send an email to '''{{emailentry|github-owners|mozilla.org|at=is}}''' and we'll respond right away! We're also available on #github on irc.

=== How do I hook up a new 3rd party application to a repository in the mozilla org? ===
{{note|There are now multiple 3rd pary application types. "GitHub Apps" (nee integrations) are the new approach and preferred.|gotcha}}
{{note|Some 3rd party apps use GitHub as an OAuth identity provider for their website (e.g. for a dashboard). An ''OAuth Application'' will block the installation process if the app is not already approved. The "Request access" block is what this section describes.|gotcha}}

Each type has it's own installation and approval process. Please follow the instructions in the correct section below.

==== GitHub Apps Installation & Approval Process ====

GitHub Apps (formerly called "integrations") are "Installed" into either the entire organization, or into individual repositories. Each integration has a documented and granular access to repository resources. This is good.

However, the GitHub App installation can only be done by an organization owner, who may have to do additional housekeeping. This is not so good, so please plan accordingly (you may need to coordinate with [[#contact|GitHub owners]]).

* File a request using this [https://bugzilla.mozilla.org/enter_bug.cgi?cc=gene%40mozilla.com&comment=I%20want%20to%20use%20the%20NAME_HERE%20addon%20in%20ORG_NAME_HERE%20for%20the%20following%20reasons%3A%0D%0A%0D%0ABelow%20are%20my%20answers%20to%20your%20stock%20questions%3A%0D%0A%0D%0A%2A%2A%20Which%20repositories%20do%20you%20want%20to%20have%20access%3F%20%28all%20or%20list%29%0D%0A%0D%0A%2A%2A%20Are%20any%20of%20those%20repositories%20private%3F%0D%0A%0D%0A%2A%2A%20Provide%20link%20to%20vendor%27s%20description%20of%20permissions%20needed%20and%20why%0D%0A%0D%0A%2A%2A%20Provide%20the%20Install%20link%20for%20a%20GitHub%20app%0D%0A&component=Github%3A%20Administration&product=mozilla.org&short_desc=Assess%20use%20of%20external%20addon%20NAME_HERE%20in%20Mozilla%27s%20GitHub%20organization%20ORG_NAME_HERE bug template]
* Include answers to these questions:
** Which repositories do you want to have access? (all or list)
** Do any of those repositories contain "sensitive" data? (e.g. private repos or ones where unauthorized code changes could have significant impact to Mozilla)
** Provide link to vendor's description of permissions needed and why
** Provide installation instructions:
*** Please include the GitHub App's "install" link

===== Initial Installation =====
If this is the first time this GitHub App is being installed in the organization, a few extra checks and coordination are needed. An organization owner will need to perform these steps:
* Determine if the GitHub App previously had an OAUTH version.
** If so, it is likely that installing the integration will disable all repositories in the organization using the OAUTH version of the application.
** Find all current repositories using the classic OAUTH application (this is non-trivial, scripts exist to help)
** Install the Integration for all current repositories, and the new one (organization owner permissions needed.)

'''Please do not install GitHub apps with organization wide scope without first discussing with [[#contact|GitHub owners]].'''

===== Additional Installations or Removals =====
If the GitHub App has already been installed in the organization, the new repository simply needs to be added or removed from the list. An organization owner has to make this change. Please still [https://bugzilla.mozilla.org/enter_bug.cgi?cc=gene%40mozilla.com&comment=I%20want%20to%20use%20the%20NAME_HERE%20addon%20in%20ORG_NAME_HERE%20for%20the%20following%20reasons%3A%0D%0A%0D%0ABelow%20are%20my%20answers%20to%20your%20stock%20questions%3A%0D%0A%0D%0A%2A%2A%20Which%20repositories%20do%20you%20want%20to%20have%20access%3F%20%28all%20or%20list%29%0D%0A%0D%0A%2A%2A%20Are%20any%20of%20those%20repositories%20private%3F%0D%0A%0D%0A%2A%2A%20Provide%20link%20to%20vendor%27s%20description%20of%20permissions%20needed%20and%20why%0D%0A%0D%0A%2A%2A%20Provide%20the%20Install%20link%20for%20a%20GitHub%20app%0D%0A&component=Github%3A%20Administration&product=mozilla.org&short_desc=Assess%20use%20of%20external%20addon%20NAME_HERE%20in%20Mozilla%27s%20GitHub%20organization%20ORG_NAME_HERE file a bug].

If you're an org owner, you can [https://github.com/organizations/mozilla/settings/installations see what has already been installed].

==== OAUTH (classic) Applications ====

* Authorizing an application to work with GitHub utilizes the permissions your account has -- so, any repositories you have access to the application will have access to as well (including private ones). If you want to grant access to an application that no one else has used with the Mozilla organization yet you'll see a "Request access" button during the set up flow. You'll need to click that button to request approval. See below for an example:

[[File:github_approval.png]]

* In some cases, the application does not need to be "approved" to function correctly, as it has read only access to any public repository. (Some applications only want write access to help you configure the application first time.)

* In other cases, the application does need write permission, and/or permission to read a private repository. In these cases, open a bug using [https://bugzilla.mozilla.org/enter_bug.cgi?cc=gene%40mozilla.com&comment=I%20want%20to%20use%20the%20NAME_HERE%20addon%20in%20ORG_NAME_HERE%20for%20the%20following%20reasons%3A%0D%0A%0D%0ABelow%20are%20my%20answers%20to%20your%20stock%20questions%3A%0D%0A%0D%0A%2A%2A%20Which%20repositories%20do%20you%20want%20to%20have%20access%3F%20%28all%20or%20list%29%0D%0A%0D%0A%2A%2A%20Are%20any%20of%20those%20repositories%20private%3F%0D%0A%0D%0A%2A%2A%20Provide%20link%20to%20vendor%27s%20description%20of%20permissions%20needed%20and%20why%0D%0A%0D%0A%2A%2A%20Provide%20the%20Install%20link%20for%20a%20GitHub%20app%0D%0A&component=Github%3A%20Administration&product=mozilla.org&short_desc=Assess%20use%20of%20external%20addon%20NAME_HERE%20in%20Mozilla%27s%20GitHub%20organization%20ORG_NAME_HERE this template].
** Please be sure to have clicked the "Request Approval" link before submitting bug.
* Include answers to these questions:
** Provide link to vendor's description of permissions needed and why
** Provide installation instructions (both may be needed):

=== Reviewing owners and permissions ===
As an owner or repository admin you're responsible for maintaining the list of people with access to your projects. Please be active and prudent about maintaining this list.

=== Can I be an Owner of the Mozilla Organization? ===
The Owners group on GitHub has complete administrative power and will be limited to a minimal number of people and reviewed regularly. If a person is an owner, they are expected to actively participate in the group and assist others as requested. Owners will be added as a need arises (for example, support in another timezone) as determined by the current owners.

=== Can I be a Member of the Mozilla Organization? ===
<div id="join"> </div>
==== Contributor Information ====
Good news! You do not need to be a member of the Mozilla organization on GitHub before you can contribute to Mozilla!!!! We have several sites which can help you find the best fit for contribution:
* General [https://www.mozilla.org/en-US/contribute/ volunteering options],
* Or pick from [http://whatcanidoformozilla.org/ these areas],
* Or jump right into [http://www.joshmatthews.net/bugsahoy/ fixing a bug].
* If you're already a contributor (THANK YOU!) looking for a place to have your work recognized (even if not coding related), please see the [https://www.mozilla.org/credits/FAQ Credits FAQ] for inclusion in the [https://www.mozilla.org/credits/ credits].

Once you're working on a project, the project leaders can help you get access to anything you need.

==== Team Maintainers & Project Leads ====

Project owners and team maintainers may find the following information helpful when asking for access for a new team member:

* We prefer the use of github teams.
* All members of the [https://github.com/mozilla/ Mozilla organization on github] agree to be bound by [https://www.mozilla.org/en-US/about/governance/policies/commit/requirements/ Mozilla's Commit Access Requirements], and should follow the intent of the [https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/ Mozilla's Commit Access Policy] as much as practical.
** "Outside Collaborator": repository admins can grant outside collaborator to any GitHub account. "Outside Collaborator" is roughly analogous to "Level 1a" access to Mozilla-hosted repositories.
** "Team Member": team maintainers can add GitHub users to a team, if they are already a member of the organization. If you are not yet a member of the organization, the team maintainer should [[#contact|request your addition]] to their team, as a form of vouching. "Team Member" is roughly analogous to "Level 2" or "Level 3", with the distinction being the content of the repositories managed by the team.

To get access for a new Contributor, please [https://bugzilla.mozilla.org/enter_bug.cgi?comment=I%27ve%20read%20https%3A%2F%2Fwiki.mozilla.org%2FGithub%23Team_Maintainers_.26_Project_Leads%2C%20and%20need%20help%20adding%20a%20contributor%20to%20the%20org%3A%0D%0A%0D%0AName%3A%20%0D%0AMozilla%20Email%3A%20%0D%0AGithub%20Profile%20link%3A%20%0D%0AGithub%20Team%28s%29%3A%20%0D%0A%0D%0AIf%20this%20is%20not%20being%20requested%20by%20a%20team%20maintainer%2C%20please%20request%20their%20approval%20via%20need-info.&component=Github%3A%20Administration&form_name=enter_bug&product=mozilla.org file a bug using this link], and fill in the details.

'''Please Note:'''
* We will cancel any invitation to the organization which is not accepted within 2 weeks.
* All members of the Mozilla organization on GitHub '''MUST''' have [https://help.github.com/articles/about-two-factor-authentication/ 2FA enabled].
* Automation accounts are also required to have 2FA enabled. Scripts should use [https://help.github.com/articles/creating-an-access-token-for-command-line-use/ access tokens] with minimum permissions to accomplish the task.

=== Should I make a separate github organization or just create a repository in an existing one? ===
This is a personal preference. If you have a large enough project or organization feel free. We suggest you use the strategies and recommendations here as a model to manage the details.

=== Forking vs Transferring ===
'''Do not "fork" a repository into a Mozilla organization.''' Doing so gives ''every team in the org'' rights to it.

If you have created a repo on your own account (for example, myuser/myrepo) and it should live under the Mozilla organization, here are the steps:

{{note|As soon as you transfer, your repository will be in "limbo" (only you will have write access). An automated process should grant you "admin" access within a few minutes. If that does not happen, please [[#contact|org admin]] who can make that change. Please plan in advance if timing is critical.}}

# If you're not a member of any team, talk to an [[#contact|org admin]].
# Under the repo admin, transfer ownership to the Mozilla organization. If you don't see this option, return to step 1.
# Choose which teams should be given access. All chosen teams will have only 'read' access at this point.
# Ask an [[#contact|org admin]] to grant team permissions higher than read ('write' and 'admin' are the other choices). (Team maintainers do not have the ability to change a repositories status.)
# Fork the repo from Mozilla (mozilla/myrepo) back to your account (recreating myuser/myrepo). While the transferred repo becomes the root of the network on GitHub (e.g. all forks are now forks of mozilla/myrepo) other users may be pointing to your repo by URL. (Optional, github will redirect old URLs for transfers, but you probably want a local repo if you use the PR workflow.)

=== Do I need to be an owner to create repositories? ===
No. If a person has read/write access to another repository in that organization they can make more repositories in that organization. However, it's preferred that you create repositories in the context of a team. Teams are created [https://github.com/orgs/mozilla/teams here], if necessary. Once you have created a repo, you can configure it to give rights to members of particular teams.

=== Are there requirements for when or how I should create a new team? ===
No. When requirements were proposed they all seemed too rigid and time consuming. Instead we recommend staying flexible and using good naming and documentation for projects (similar to naming CSS classes or variables).

On large teams we recommend you separate teams for read/write and repository administration.

<div id="other_github"></div>
=== Is "mozilla" the only github "organization" related to Mozilla? ===
No, there are plenty of Mozilla-related "organizations" on github. As a rule of thumb, initiatives that create a large number of sub-repositories will create their own "organization". Here is a (probably incomplete) list of them:
{| class="wikitable sortable"
|-
! Organization !! Description !! Contact Owner
|-
| [https://github.com/mozilla-it mozilla-it] || Mozilla IT's repositories || ?
|-
|[https://github.com/mozillabrasil mozillabrasil] || Mozilla Brazil|| ?
|-
| [https://github.com/bugzilla bugzilla] || Bugzilla (the product, not bugzilla.mozilla.org) || #bugzilla
|-
| [https://github.com/drumbeat-badge-sprint drumbeat-badge-sprint] || Drumbeat Badge Lab || ?
|-
| [https://github.com/hackasaurus hackasaurus] || Hackasaurus || ?
|-
| [https://github.com/jetpack-labs jetpack-labs] || Jetpack Labs || ?
|-
| [https://github.com/mdn mdn] || Mozilla Developer Network || [https://github.com/jwhitlock John Whitlock]
|-
| [https://github.com/mozbrick mozbrick] || Mozilla Brick (web components library) || ?
|-
| [https://github.com/mozilla-appmaker mozilla-appmaker] || Mozilla Appmaker || ?
|-
| [https://github.com/mozilla-b2g mozilla-b2g] || Mozilla Boot2Gecko / Firefox OS || ?
|-
| [https://github.com/mozilla-bteam mozilla-bteam] || Bugzilla.Mozilla.org || #bteam
|-
| [https://github.com/mozilla-cit mozilla-cit] || Mozilla Community Ops || {{Mozillians|tanner|Tanner Filip}} or {{Mozillians|yalam96|Yousef Alam}}
|-
| [https://github.com/mozilla-comm mozilla-comm] || Calendaring and Messaging related projects || ?
|-
| [https://github.com/mozilla-cordova mozilla-cordova] || Firefox OS Support for Apache Cordova || ?
|-
| [https://github.com/mozilla-iam mozilla-iam] || Mozilla's identity and access management || kang
|-
| [https://github.com/mozilla-platform-ops mozilla-platform-ops] || Mozilla Platform Operations || [[Platform_Operations]]
|-
| [https://github.com/mozilla-metrics mozilla-metrics] || Mozilla Metrics || ?
|-
| [https://github.com/mozilla-raptor mozilla-raptor] || Mozilla Raptor / Firefox OS Performance || {{Mozillian|eliperelman|Eli Perelman}}, {{Mozillian|rwood|Rob Wood}}
|-
| [https://github.com/mozilla-releng mozilla-releng] || Mozilla Release Engineering || #releng
|-
| [https://github.com/mozilla-services mozilla-services] || Mozilla Services || [https://github.com/orgs/mozilla-services/people?utf8=%E2%9C%93&query=role%3Aowner mozilla-services owners]
|-
| [https://github.com/mozilla-standards mozilla-standards] || Mozilla Standards (for IPR Contributions) || [https://mozillians.org/u/dbaron/ dbaron], [https://mozillians.org/u/annevk/ annevk]
|-
| [https://github.com/mozilla-svcops mozilla-svcops] || Mozilla Cloud Services Ops || {{Mozillian|relud|Daniel Thornton}}
|-
| [https://github.com/Mozilla-TWQA Mozilla-TWQA] || Mozilla Taiwan QA || ?
|-
| [https://github.com/mozillahispano mozillahispano] || Mozilla Hispano || ?
|-
| [https://github.com/MozillaScience MozillaScience] || Mozilla Science Lab || ?
|-
| [https://github.com/MozillaSecurity MozillaSecurity] || Mozilla Platform Fuzzing Team master repo with many fuzzing tools under it. || ?
|-
| [https://github.com/MozillaWiki MozillaWiki] || MozillaWiki (wiki.mozilla.org) || {{Mozillian|ckoehler|Christie Koehler}}, {{Mozillian|gphemsley|Gordon P. Hemsley}}
|-
| [https://github.com/mozillayvr mozillayvr] || Mozilla Vancouver @MozillaYVR || {{Mozillian|bclark|Brian Clark}}, {{Mozillian|shobson|Stephanie Hobson}}
|-
| [https://github.com/mozfr mozfr] || Mozilla Francophone || Pascal Chevrel https://mozillians.org/fr/u/pascalc/
|-
| [https://github.com/opennews opennews] || Knight-Mozilla OpenNews || ?
|-
| [https://github.com/rust-lang rust-lang] || The Rust Programming Language || {{Mozillian|aturon|Aaron Turon}}
|-
| [https://github.com/servo servo] || Servo (browser engine written in Rust) || {{Mozillian|larsberg|Lars Bergstrom}}, Jack Moffitt
|-
| [https://github.com/tabulapdf tabulapdf] || Tabula project (extract data from PDF files) || ?
|-
| [https://github.com/webcompat webcompat] || Web Compatibility Team || {{Mozillian|miketaylr|Mike Taylor}}
|-
| [https://github.com/mozilla-l10n mozilla-l10n] || Mozilla l10n-drivers team || Pascal Chevrel https://mozillians.org/fr/u/pascalc/
|-
| [https://github.com/taskcluster taskcluster] || [[TaskCluster]] Team || [https://github.com/gregarndt Greg Arndt]
|-
| [https://github.com/MozillaCH MozillaCH] || Mozilla [[Switzerland]] || {{Mozillian|mkohler|Michael Kohler}}, {{Mozillian|freaktechnik|freaktechnik}}
|-
| [https://github.com/mozmar mozmar] || Mozilla [[Marketing]] || {{Mozillian|bensternthal|Benjamin Sternthal}}, {{Mozillian|pmac|Paul McLanahan}}
|-
| [https://github.com/mozilla-payments mozilla-payments] || Implementation of Web Payment APIs || {{Mozillian|Marcos Caceres}}
|-
| [https://github.com/mozilla-jetpack mozilla-jetpack] || Resources for Mozilla's Add-on SDK || ?
|-
| [https://github.com/web-ext-experiments web-ext-experiments] || WebExtension API Experiments || {{Mozillian|andym|Andy McKay}}
|-
| [https://github.com/mozilla-conduit mozilla-conduit] || Mozilla Conduit work || {{Mozillian|mcote|Mark Côté}}
|-
| [https://github.com/mozsearch mozsearch] || The code that runs Searchfox.org || {{Mozillian|kats|Kartikaya Gupta}}
|-
| [https://github.com/MozillaCZ/ MozillaCZ] || [https://www.mozilla.cz/ Mozilla.cz] || {{Mozillian|mstanke|Michal Stanke}}, {{Mozillian|MekliCZ|Michal Vašíček}}, {{Mozillian|zelitomas|Tomáš Zelina}}
|-
| [https://github.com/MozillaSK/ MozillaSK] || [https://www.mozilla.sk/ Mozilla.sk] || {{Mozillian|mstanke|Michal Stanke}}, {{Mozillian|kusavica|Juraj Cigáň}}
|}

=== Are there other unofficial or Mozilla-related repositories hosted on Github? ===
Why, yes! In no particular order:

* [https://github.com/kinetiknz/cubeb/ https://github.com/kinetiknz/cubeb/] : Cubeb cross platform audio library.
* [https://github.com/djg/cubeb-rs/ https://github.com/djg/cubeb-rs/] : Rust bindings for cubeb.
* [https://github.com/kinetiknz/nestegg/ https://github.com/kinetiknz/nestegg/] : WebM demuxer.
* [https://github.com/xiph/opus/ https://github.com/xiph/opus/] : Modern audio compression for the internet.
* [https://github.com/webmproject/libvpx https://github.com/webmproject/libvpx] : Mirror only. Please do not send pull requests.
* [https://github.com/campd/fxdt-adapters https://github.com/campd/fxdt-adapters] : Firefox Developer Tools protocol adapters
* [https://github.com/kripken/emscripten https://github.com/kripken/emscripten] : Emscripten: An LLVM-to-JavaScript Compiler
* [https://github.com/bbondy/codefirefox https://github.com/bbondy/codefirefox] : Video and exercise based tutorial site for coding Firefox and other Mozilla related technology
* [https://github.com/nickdesaulniers/where-is-firefox-os https://github.com/nickdesaulniers/where-is-firefox-os] : A map showing where in the world Firefox OS phones are being sold.
* [https://github.com/jdm/bugsahoy https://github.com/jdm/bugsahoy] : A landing page to make finding relevant bugs easier for new Mozilla contributors.
* [https://github.com/w3c/web-platform-tests https://github.com/w3c/web-platform-tests] : Test Suites for Web Platform specifications
* [https://github.com/w3c/wptserve https://github.com/w3c/wptserve] : Web server designed for use with web-platform-tests
* [https://github.com/w3c/wptrunner https://github.com/w3c/wptrunner] : Cross-browser and multi-platform test runner for web-platform-tests. Used in mozilla-central and servo.
* [https://github.com/w3c/testharness.js https://github.com/w3c/testharness.js] : (no description)
* [https://github.com/jdm/asknot https://github.com/jdm/asknot] : Ask not what Mozilla can do for you but what you can do for Mozilla.
* [https://github.com/jeffbryner/MozDef https://github.com/jeffbryner/MozDef]: Mozilla Defense Platform.
* [https://github.com/jgraham/webdriver-rust https://github.com/jgraham/webdriver-rust]: WebDriver library for Rust.
* [https://github.com/ehsan/mozilla-cvs-history https://github.com/ehsan/mozilla-cvs-history]: A git conversion of the full Mozilla CVS history, useful for code archaeology.
* [https://github.com/djg/audioipc-2 https://github.com/djg/audioipc-2]: Audio IPC for Gecko.
* [https://github.com/hsivonen/encoding_rs https://github.com/hsivonen/encoding_rs]: encoding_rs (character encoding converters for Gecko)

GitHub

2018-03-08T14:02:45Z

Hsivonen: List encoding_rs

This page is specifically about [https://github.com/mozilla the "mozilla" organization on github]. There are several other github organizations you may be interested in, cf. the incomplete list [[#other_github|below]].
<div id="contact">
{| class="wikitable"
|-
! [[File:Red_question_mark.png|144px|Send us an email!|link=]] Got a question?
|-
| Email {{emailentry|github-owners|mozilla.org|at=is}} 
Bugzilla [https://bugzilla.mozilla.org/enter_bug.cgi?comment=I%27ve%20read%20https%3A%2F%2Fwiki.mozilla.org%2FGithub%2C%20and%20need%20help%20with%20the%20following.%0D%0A%0D%0A&component=Github%3A%20Administration&form_name=enter_bug&product=mozilla.org& mozilla.org :: Github: Administration] 
irc #github on [[IRC|moznet]]
|}

== News ==
* As of June 20, 2016, all members [https://groups.google.com/forum/#!topic/mozilla.dev.platform/UmHOOh3qtiM must have 2FA enabled]. You have been notified if this impacts you.

== Recommendations and FAQ ==

=== Where should I ask additional questions? ===
* Send an email to '''{{emailentry|github-owners|mozilla.org|at=is}}''' and we'll respond right away! We're also available on #github on irc.

=== How do I hook up a new 3rd party application to a repository in the mozilla org? ===
{{note|There are now multiple 3rd pary application types. "GitHub Apps" (nee integrations) are the new approach and preferred.|gotcha}}
{{note|Some 3rd party apps use GitHub as an OAuth identity provider for their website (e.g. for a dashboard). An ''OAuth Application'' will block the installation process if the app is not already approved. The "Request access" block is what this section describes.|gotcha}}

Each type has it's own installation and approval process. Please follow the instructions in the correct section below.

==== GitHub Apps Installation & Approval Process ====

GitHub Apps (formerly called "integrations") are "Installed" into either the entire organization, or into individual repositories. Each integration has a documented and granular access to repository resources. This is good.

However, the GitHub App installation can only be done by an organization owner, who may have to do additional housekeeping. This is not so good, so please plan accordingly (you may need to coordinate with [[#contact|GitHub owners]]).

* File a request using this [https://bugzilla.mozilla.org/enter_bug.cgi?cc=gene%40mozilla.com&comment=I%20want%20to%20use%20the%20NAME_HERE%20addon%20in%20ORG_NAME_HERE%20for%20the%20following%20reasons%3A%0D%0A%0D%0ABelow%20are%20my%20answers%20to%20your%20stock%20questions%3A%0D%0A%0D%0A%2A%2A%20Which%20repositories%20do%20you%20want%20to%20have%20access%3F%20%28all%20or%20list%29%0D%0A%0D%0A%2A%2A%20Are%20any%20of%20those%20repositories%20private%3F%0D%0A%0D%0A%2A%2A%20Provide%20link%20to%20vendor%27s%20description%20of%20permissions%20needed%20and%20why%0D%0A%0D%0A%2A%2A%20Provide%20the%20Install%20link%20for%20a%20GitHub%20app%0D%0A&component=Github%3A%20Administration&product=mozilla.org&short_desc=Assess%20use%20of%20external%20addon%20NAME_HERE%20in%20Mozilla%27s%20GitHub%20organization%20ORG_NAME_HERE bug template]
* Include answers to these questions:
** Which repositories do you want to have access? (all or list)
** Do any of those repositories contain "sensitive" data? (e.g. private repos or ones where unauthorized code changes could have significant impact to Mozilla)
** Provide link to vendor's description of permissions needed and why
** Provide installation instructions:
*** Please include the GitHub App's "install" link

===== Initial Installation =====
If this is the first time this GitHub App is being installed in the organization, a few extra checks and coordination are needed. An organization owner will need to perform these steps:
* Determine if the GitHub App previously had an OAUTH version.
** If so, it is likely that installing the integration will disable all repositories in the organization using the OAUTH version of the application.
** Find all current repositories using the classic OAUTH application (this is non-trivial, scripts exist to help)
** Install the Integration for all current repositories, and the new one (organization owner permissions needed.)

'''Please do not install GitHub apps with organization wide scope without first discussing with [[#contact|GitHub owners]].'''

===== Additional Installations or Removals =====
If the GitHub App has already been installed in the organization, the new repository simply needs to be added or removed from the list. An organization owner has to make this change. Please still [https://bugzilla.mozilla.org/enter_bug.cgi?cc=gene%40mozilla.com&comment=I%20want%20to%20use%20the%20NAME_HERE%20addon%20in%20ORG_NAME_HERE%20for%20the%20following%20reasons%3A%0D%0A%0D%0ABelow%20are%20my%20answers%20to%20your%20stock%20questions%3A%0D%0A%0D%0A%2A%2A%20Which%20repositories%20do%20you%20want%20to%20have%20access%3F%20%28all%20or%20list%29%0D%0A%0D%0A%2A%2A%20Are%20any%20of%20those%20repositories%20private%3F%0D%0A%0D%0A%2A%2A%20Provide%20link%20to%20vendor%27s%20description%20of%20permissions%20needed%20and%20why%0D%0A%0D%0A%2A%2A%20Provide%20the%20Install%20link%20for%20a%20GitHub%20app%0D%0A&component=Github%3A%20Administration&product=mozilla.org&short_desc=Assess%20use%20of%20external%20addon%20NAME_HERE%20in%20Mozilla%27s%20GitHub%20organization%20ORG_NAME_HERE file a bug].

If you're an org owner, you can [https://github.com/organizations/mozilla/settings/installations see what has already been installed].

==== OAUTH (classic) Applications ====

* Authorizing an application to work with GitHub utilizes the permissions your account has -- so, any repositories you have access to the application will have access to as well (including private ones). If you want to grant access to an application that no one else has used with the Mozilla organization yet you'll see a "Request access" button during the set up flow. You'll need to click that button to request approval. See below for an example:

[[File:github_approval.png]]

* In some cases, the application does not need to be "approved" to function correctly, as it has read only access to any public repository. (Some applications only want write access to help you configure the application first time.)

* In other cases, the application does need write permission, and/or permission to read a private repository. In these cases, open a bug using [https://bugzilla.mozilla.org/enter_bug.cgi?cc=gene%40mozilla.com&comment=I%20want%20to%20use%20the%20NAME_HERE%20addon%20in%20ORG_NAME_HERE%20for%20the%20following%20reasons%3A%0D%0A%0D%0ABelow%20are%20my%20answers%20to%20your%20stock%20questions%3A%0D%0A%0D%0A%2A%2A%20Which%20repositories%20do%20you%20want%20to%20have%20access%3F%20%28all%20or%20list%29%0D%0A%0D%0A%2A%2A%20Are%20any%20of%20those%20repositories%20private%3F%0D%0A%0D%0A%2A%2A%20Provide%20link%20to%20vendor%27s%20description%20of%20permissions%20needed%20and%20why%0D%0A%0D%0A%2A%2A%20Provide%20the%20Install%20link%20for%20a%20GitHub%20app%0D%0A&component=Github%3A%20Administration&product=mozilla.org&short_desc=Assess%20use%20of%20external%20addon%20NAME_HERE%20in%20Mozilla%27s%20GitHub%20organization%20ORG_NAME_HERE this template].
** Please be sure to have clicked the "Request Approval" link before submitting bug.
* Include answers to these questions:
** Provide link to vendor's description of permissions needed and why
** Provide installation instructions (both may be needed):

=== Reviewing owners and permissions ===
As an owner or repository admin you're responsible for maintaining the list of people with access to your projects. Please be active and prudent about maintaining this list.

=== Can I be an Owner of the Mozilla Organization? ===
The Owners group on GitHub has complete administrative power and will be limited to a minimal number of people and reviewed regularly. If a person is an owner, they are expected to actively participate in the group and assist others as requested. Owners will be added as a need arises (for example, support in another timezone) as determined by the current owners.

=== Can I be a Member of the Mozilla Organization? ===
<div id="join"> </div>
==== Contributor Information ====
Good news! You do not need to be a member of the Mozilla organization on GitHub before you can contribute to Mozilla!!!! We have several sites which can help you find the best fit for contribution:
* General [https://www.mozilla.org/en-US/contribute/ volunteering options],
* Or pick from [http://whatcanidoformozilla.org/ these areas],
* Or jump right into [http://www.joshmatthews.net/bugsahoy/ fixing a bug].
* If you're already a contributor (THANK YOU!) looking for a place to have your work recognized (even if not coding related), please see the [https://www.mozilla.org/credits/FAQ Credits FAQ] for inclusion in the [https://www.mozilla.org/credits/ credits].

Once you're working on a project, the project leaders can help you get access to anything you need.

==== Team Maintainers & Project Leads ====

Project owners and team maintainers may find the following information helpful when asking for access for a new team member:

* We prefer the use of github teams.
* All members of the [https://github.com/mozilla/ Mozilla organization on github] agree to be bound by [https://www.mozilla.org/en-US/about/governance/policies/commit/requirements/ Mozilla's Commit Access Requirements], and should follow the intent of the [https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/ Mozilla's Commit Access Policy] as much as practical.
** "Outside Collaborator": repository admins can grant outside collaborator to any GitHub account. "Outside Collaborator" is roughly analogous to "Level 1a" access to Mozilla-hosted repositories.
** "Team Member": team maintainers can add GitHub users to a team, if they are already a member of the organization. If you are not yet a member of the organization, the team maintainer should [[#contact|request your addition]] to their team, as a form of vouching. "Team Member" is roughly analogous to "Level 2" or "Level 3", with the distinction being the content of the repositories managed by the team.

To get access for a new Contributor, please [https://bugzilla.mozilla.org/enter_bug.cgi?comment=I%27ve%20read%20https%3A%2F%2Fwiki.mozilla.org%2FGithub%23Team_Maintainers_.26_Project_Leads%2C%20and%20need%20help%20adding%20a%20contributor%20to%20the%20org%3A%0D%0A%0D%0AName%3A%20%0D%0AMozilla%20Email%3A%20%0D%0AGithub%20Profile%20link%3A%20%0D%0AGithub%20Team%28s%29%3A%20%0D%0A%0D%0AIf%20this%20is%20not%20being%20requested%20by%20a%20team%20maintainer%2C%20please%20request%20their%20approval%20via%20need-info.&component=Github%3A%20Administration&form_name=enter_bug&product=mozilla.org file a bug using this link], and fill in the details.

'''Please Note:'''
* We will cancel any invitation to the organization which is not accepted within 2 weeks.
* All members of the Mozilla organization on GitHub '''MUST''' have [https://help.github.com/articles/about-two-factor-authentication/ 2FA enabled].
* Automation accounts are also required to have 2FA enabled. Scripts should use [https://help.github.com/articles/creating-an-access-token-for-command-line-use/ access tokens] with minimum permissions to accomplish the task.

=== Should I make a separate github organization or just create a repository in an existing one? ===
This is a personal preference. If you have a large enough project or organization feel free. We suggest you use the strategies and recommendations here as a model to manage the details.

=== Forking vs Transferring ===
'''Do not "fork" a repository into a Mozilla organization.''' Doing so gives ''every team in the org'' rights to it.

If you have created a repo on your own account (for example, myuser/myrepo) and it should live under the Mozilla organization, here are the steps:

{{note|As soon as you transfer, your repository will be in "limbo" (only you will have write access). An automated process should grant you "admin" access within a few minutes. If that does not happen, please [[#contact|org admin]] who can make that change. Please plan in advance if timing is critical.}}

# If you're not a member of any team, talk to an [[#contact|org admin]].
# Under the repo admin, transfer ownership to the Mozilla organization. If you don't see this option, return to step 1.
# Choose which teams should be given access. All chosen teams will have only 'read' access at this point.
# Ask an [[#contact|org admin]] to grant team permissions higher than read ('write' and 'admin' are the other choices). (Team maintainers do not have the ability to change a repositories status.)
# Fork the repo from Mozilla (mozilla/myrepo) back to your account (recreating myuser/myrepo). While the transferred repo becomes the root of the network on GitHub (e.g. all forks are now forks of mozilla/myrepo) other users may be pointing to your repo by URL. (Optional, github will redirect old URLs for transfers, but you probably want a local repo if you use the PR workflow.)

=== Do I need to be an owner to create repositories? ===
No. If a person has read/write access to another repository in that organization they can make more repositories in that organization. However, it's preferred that you create repositories in the context of a team. Teams are created [https://github.com/orgs/mozilla/teams here], if necessary. Once you have created a repo, you can configure it to give rights to members of particular teams.

=== Are there requirements for when or how I should create a new team? ===
No. When requirements were proposed they all seemed too rigid and time consuming. Instead we recommend staying flexible and using good naming and documentation for projects (similar to naming CSS classes or variables).

On large teams we recommend you separate teams for read/write and repository administration.

<div id="other_github"></div>
=== Is "mozilla" the only github "organization" related to Mozilla? ===
No, there are plenty of Mozilla-related "organizations" on github. As a rule of thumb, initiatives that create a large number of sub-repositories will create their own "organization". Here is a (probably incomplete) list of them:
{| class="wikitable sortable"
|-
! Organization !! Description !! Contact Owner
|-
| [https://github.com/mozilla-it mozilla-it] || Mozilla IT's repositories || ?
|-
|[https://github.com/mozillabrasil mozillabrasil] || Mozilla Brazil|| ?
|-
| [https://github.com/bugzilla bugzilla] || Bugzilla (the product, not bugzilla.mozilla.org) || #bugzilla
|-
| [https://github.com/drumbeat-badge-sprint drumbeat-badge-sprint] || Drumbeat Badge Lab || ?
|-
| [https://github.com/hackasaurus hackasaurus] || Hackasaurus || ?
|-
| [https://github.com/jetpack-labs jetpack-labs] || Jetpack Labs || ?
|-
| [https://github.com/mdn mdn] || Mozilla Developer Network || [https://github.com/jwhitlock John Whitlock]
|-
| [https://github.com/mozbrick mozbrick] || Mozilla Brick (web components library) || ?
|-
| [https://github.com/mozilla-appmaker mozilla-appmaker] || Mozilla Appmaker || ?
|-
| [https://github.com/mozilla-b2g mozilla-b2g] || Mozilla Boot2Gecko / Firefox OS || ?
|-
| [https://github.com/mozilla-bteam mozilla-bteam] || Bugzilla.Mozilla.org || #bteam
|-
| [https://github.com/mozilla-cit mozilla-cit] || Mozilla Community Ops || {{Mozillians|tanner|Tanner Filip}} or {{Mozillians|yalam96|Yousef Alam}}
|-
| [https://github.com/mozilla-comm mozilla-comm] || Calendaring and Messaging related projects || ?
|-
| [https://github.com/mozilla-cordova mozilla-cordova] || Firefox OS Support for Apache Cordova || ?
|-
| [https://github.com/mozilla-iam mozilla-iam] || Mozilla's identity and access management || kang
|-
| [https://github.com/mozilla-platform-ops mozilla-platform-ops] || Mozilla Platform Operations || [[Platform_Operations]]
|-
| [https://github.com/mozilla-metrics mozilla-metrics] || Mozilla Metrics || ?
|-
| [https://github.com/mozilla-raptor mozilla-raptor] || Mozilla Raptor / Firefox OS Performance || {{Mozillian|eliperelman|Eli Perelman}}, {{Mozillian|rwood|Rob Wood}}
|-
| [https://github.com/mozilla-releng mozilla-releng] || Mozilla Release Engineering || #releng
|-
| [https://github.com/mozilla-services mozilla-services] || Mozilla Services || [https://github.com/orgs/mozilla-services/people?utf8=%E2%9C%93&query=role%3Aowner mozilla-services owners]
|-
| [https://github.com/mozilla-standards mozilla-standards] || Mozilla Standards (for IPR Contributions) || [https://mozillians.org/u/dbaron/ dbaron], [https://mozillians.org/u/annevk/ annevk]
|-
| [https://github.com/mozilla-svcops mozilla-svcops] || Mozilla Cloud Services Ops || {{Mozillian|relud|Daniel Thornton}}
|-
| [https://github.com/Mozilla-TWQA Mozilla-TWQA] || Mozilla Taiwan QA || ?
|-
| [https://github.com/mozillahispano mozillahispano] || Mozilla Hispano || ?
|-
| [https://github.com/MozillaScience MozillaScience] || Mozilla Science Lab || ?
|-
| [https://github.com/MozillaSecurity MozillaSecurity] || Mozilla Platform Fuzzing Team master repo with many fuzzing tools under it. || ?
|-
| [https://github.com/MozillaWiki MozillaWiki] || MozillaWiki (wiki.mozilla.org) || {{Mozillian|ckoehler|Christie Koehler}}, {{Mozillian|gphemsley|Gordon P. Hemsley}}
|-
| [https://github.com/mozillayvr mozillayvr] || Mozilla Vancouver @MozillaYVR || {{Mozillian|bclark|Brian Clark}}, {{Mozillian|shobson|Stephanie Hobson}}
|-
| [https://github.com/mozfr mozfr] || Mozilla Francophone || Pascal Chevrel https://mozillians.org/fr/u/pascalc/
|-
| [https://github.com/opennews opennews] || Knight-Mozilla OpenNews || ?
|-
| [https://github.com/rust-lang rust-lang] || The Rust Programming Language || {{Mozillian|aturon|Aaron Turon}}
|-
| [https://github.com/servo servo] || Servo (browser engine written in Rust) || {{Mozillian|larsberg|Lars Bergstrom}}, Jack Moffitt
|-
| [https://github.com/tabulapdf tabulapdf] || Tabula project (extract data from PDF files) || ?
|-
| [https://github.com/webcompat webcompat] || Web Compatibility Team || {{Mozillian|miketaylr|Mike Taylor}}
|-
| [https://github.com/mozilla-l10n mozilla-l10n] || Mozilla l10n-drivers team || Pascal Chevrel https://mozillians.org/fr/u/pascalc/
|-
| [https://github.com/taskcluster taskcluster] || [[TaskCluster]] Team || [https://github.com/gregarndt Greg Arndt]
|-
| [https://github.com/MozillaCH MozillaCH] || Mozilla [[Switzerland]] || {{Mozillian|mkohler|Michael Kohler}}, {{Mozillian|freaktechnik|freaktechnik}}
|-
| [https://github.com/mozmar mozmar] || Mozilla [[Marketing]] || {{Mozillian|bensternthal|Benjamin Sternthal}}, {{Mozillian|pmac|Paul McLanahan}}
|-
| [https://github.com/mozilla-payments mozilla-payments] || Implementation of Web Payment APIs || {{Mozillian|Marcos Caceres}}
|-
| [https://github.com/mozilla-jetpack mozilla-jetpack] || Resources for Mozilla's Add-on SDK || ?
|-
| [https://github.com/web-ext-experiments web-ext-experiments] || WebExtension API Experiments || {{Mozillian|andym|Andy McKay}}
|-
| [https://github.com/mozilla-conduit mozilla-conduit] || Mozilla Conduit work || {{Mozillian|mcote|Mark Côté}}
|-
| [https://github.com/mozsearch mozsearch] || The code that runs Searchfox.org || {{Mozillian|kats|Kartikaya Gupta}}
|-
| [https://github.com/MozillaCZ/ MozillaCZ] || [https://www.mozilla.cz/ Mozilla.cz] || {{Mozillian|mstanke|Michal Stanke}}, {{Mozillian|MekliCZ|Michal Vašíček}}, {{Mozillian|zelitomas|Tomáš Zelina}}
|-
| [https://github.com/MozillaSK/ MozillaSK] || [https://www.mozilla.sk/ Mozilla.sk] || {{Mozillian|mstanke|Michal Stanke}}, {{Mozillian|kusavica|Juraj Cigáň}}
|}

=== Are there other unofficial or Mozilla-related repositories hosted on Github? ===
Why, yes! In no particular order:

* [https://github.com/kinetiknz/cubeb/ https://github.com/kinetiknz/cubeb/] : Cubeb cross platform audio library.
* [https://github.com/djg/cubeb-rs/ https://github.com/djg/cubeb-rs/] : Rust bindings for cubeb.
* [https://github.com/kinetiknz/nestegg/ https://github.com/kinetiknz/nestegg/] : WebM demuxer.
* [https://github.com/xiph/opus/ https://github.com/xiph/opus/] : Modern audio compression for the internet.
* [https://github.com/webmproject/libvpx https://github.com/webmproject/libvpx] : Mirror only. Please do not send pull requests.
* [https://github.com/campd/fxdt-adapters https://github.com/campd/fxdt-adapters] : Firefox Developer Tools protocol adapters
* [https://github.com/kripken/emscripten https://github.com/kripken/emscripten] : Emscripten: An LLVM-to-JavaScript Compiler
* [https://github.com/bbondy/codefirefox https://github.com/bbondy/codefirefox] : Video and exercise based tutorial site for coding Firefox and other Mozilla related technology
* [https://github.com/nickdesaulniers/where-is-firefox-os https://github.com/nickdesaulniers/where-is-firefox-os] : A map showing where in the world Firefox OS phones are being sold.
* [https://github.com/jdm/bugsahoy https://github.com/jdm/bugsahoy] : A landing page to make finding relevant bugs easier for new Mozilla contributors.
* [https://github.com/w3c/web-platform-tests https://github.com/w3c/web-platform-tests] : Test Suites for Web Platform specifications
* [https://github.com/w3c/wptserve https://github.com/w3c/wptserve] : Web server designed for use with web-platform-tests
* [https://github.com/w3c/wptrunner https://github.com/w3c/wptrunner] : Cross-browser and multi-platform test runner for web-platform-tests. Used in mozilla-central and servo.
* [https://github.com/w3c/testharness.js https://github.com/w3c/testharness.js] : (no description)
* [https://github.com/jdm/asknot https://github.com/jdm/asknot] : Ask not what Mozilla can do for you but what you can do for Mozilla.
* [https://github.com/jeffbryner/MozDef https://github.com/jeffbryner/MozDef]: Mozilla Defense Platform.
* [https://github.com/jgraham/webdriver-rust https://github.com/jgraham/webdriver-rust]: WebDriver library for Rust.
* [https://github.com/ehsan/mozilla-cvs-history https://github.com/ehsan/mozilla-cvs-history]: A git conversion of the full Mozilla CVS history, useful for code archaeology.
* [https://github.com/djg/audioipc-2 https://github.com/djg/audioipc-2]: Audio IPC for Gecko.
* [https://github.com/hsivonen/encoding_rs]: encoding_rs (character encoding converters for Gecko)

Buildbot/Talos/Tests

2017-09-07T10:49:28Z

Hsivonen: Document IsASCII and IsUTF8 benches

= Talos Tests =

== Where to get this information ==
* Talos tests are defined in [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py test.py]
* Treeherder abbreviations are defined in [https://github.com/mozilla/treeherder-service/blob/master/treeherder/etl/buildbot.py#L796 buildbot.py]
* Talos suites are configured for production in [https://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla-tests/config.py config.py]; these names are mapped to Treeherder via regexes: [https://github.com/mozilla/treeherder-service/blob/master/treeherder/etl/buildbot.py#L344 buildbot.py]

== Talos Test Types ==

There are two different species of Talos tests:

* [[#Startup Tests]] : start up the browser and wait for either the load event or the paint event and exit, measuring the time
* [[#Page Load Tests]] : load a manifest of pages

=== Startup Tests ===
[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/startup_test Startup tests] launch Firefox and measure the time to the onload or paint events. We run this in a series of cycles (default to 20) to generate a full set of data. Tests that currently are startup tests are:
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#ts_paint ts_paint]
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#tpaint tpaint]
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#tresize tresize]
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#sessionrestore.2Fsessionrestore_no_auto_restore.2Fsessionrestore_many_windows sessionrestore[_no_auto_restore/_many_windows]]
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#CanvasMark tcanvasmark] (this is the one test that is a startup test but unique as we run 5 cycles and report a series of numbers)

=== Page Load Tests ===
Many of the talos tests use the page loader to load a manifest of pages.
These are tests that load a specific page and measure the time it takes to load the page, scroll the page, draw the page etc. In order to run a page load test, you need a manifest of pages to run. The manifest is simply a list of URLs of pages to load, separated by carriage returns, e.g.:
<pre>
https://www.mozilla.org
https://www.mozilla.com
</pre>
Example: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/svgx/svgx.manifest svgx.manifest]

Manifests may also specify that a test computes its own data by prepending a <tt>%</tt> in front of the line:
<pre>
% https://www.mozilla.org
% https://www.mozilla.com
</pre>
Example: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/v8_7/v8.manifest v8.manifest]

The file you created should be referenced in your test config inside of [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l607 test.py]]. for example, open test.py, and look for the line referring to the test you want to run:
<pre>
tpmanifest = '${talos}/page_load_test/svgx/svgx.manifest'
tpcycles = 1 # run a single cycle
tppagecycles = 25 # load each page 25 times before moving onto the next page
</pre>

=== Paint Tests ===
Paint tests are measuring the time to receive both the [https://developer.mozilla.org/en/Gecko-Specific_DOM_Events#MozAfterPaint MozAfterPaint] and OnLoad event instead of just the OnLoad event. Most tests now look for this unless they are an ASAP test, or an internal benchmark

=== ASAP Tests ===
We have a variety of tests which we now run in ASAP mode where we render as fast as possible (disabling vsync and letting the rendering iterate as fast as it can using `requestAnimationFrame`). In fact we have replaced some original tests with the 'x' versions to make them measure. We do this with RequestAnimationFrame().

ASAP Tests are:
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#tsvg.2C_tsvgx svgx]
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#tscroll.2C_tscrollx tscrollx]
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#tp5o_scroll tp5o_scroll]
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#tps tps]
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#TART.2FCART tart/cart]

=== Internal Benchmarks ===
Many tests have internal benchmarks which we report as accurately as possible. These are the exceptions to the general rule of calculating the suite score as a geometric mean of the subtest values (which are median values of the raw data from the subtests).

Tests which are imported benchmarks are:
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#CanvasMark Canvasmark]
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#V8.2C_version_7 V8 Version 7]
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#kraken Kraken]
* [https://wiki.mozilla.org/Buildbot/Talos/Tests#JSS.2FDomaeo_Tests Dromaeo]

=== Row Major vs. Column Major ===

To get more stable numbers, tests are run multiple times. There are two ways that we do this: row major and column major. Row major means each test is run multiple times and then we move to the next test (and run it multiple times). Column major means that each test is run once one after the other and then the whole sequence of tests is run again.

More background information about these approaches can be found in Joel Maher's [https://elvis314.wordpress.com/2012/03/12/reducing-the-noise-in-talos/ Reducing the Noise in Talos] blog post.

=== tp5n pages set ===

Some tests make use of a set of 50 "real world" pages, known as the tp5n set. These pages are not part of the talos repository, but without them the tests which use them won't run.
* To add these pages to your local setup, download [https://people.mozilla.org/~jmaher/taloszips/zips/tp5n.zip tp5n.zip], and extract it such that `'''tp5n'''` ends up as `testing/talos/talos/tests/'''tp5n'''`.
* see also [[#tp5|tp5 test]].

== Test Descriptions ==
=== Basic Compositor Video ===
* contact: :ethlin, :avih
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/video video]
* type: [https://wiki.mozilla.org/Buildbot/Talos#Page_Load_Tests PageLoader]
* data: 12 cycles of the entire benchmark, each subtest will have 12 data points (see below)
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 11; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l522 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 24 subtest results.
* '''Lower is better'''
* unit: ms/frame

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
|basic_compositor_video
|
|}

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
;0;240p.120fps.mp4_scale_fullscreen_startup;11.112;11.071;11.196;11.157;11.195;11.240;11.196;11.155;11.237;11.074;11.154;11.282
;1;240p.120fps.mp4_scale_fullscreen_inclip;10.995;11.114;11.052;10.991;10.876;11.115;10.995;10.991;10.997;10.994;10.992;10.993
;2;240p.120fps.mp4_scale_1_startup;1.686;1.690;1.694;1.683;1.689;1.692;1.686;1.692;1.689;1.704;1.684;1.686
;3;240p.120fps.mp4_scale_1_inclip;1.666;1.666;1.666;1.668;1.667;1.669;1.667;1.668;1.668;1.667;1.667;1.669
;4;240p.120fps.mp4_scale_1.1_startup;1.677;1.672;1.673;1.677;1.673;1.677;1.672;1.677;1.677;1.671;1.676;1.679
;5;240p.120fps.mp4_scale_1.1_inclip;1.667;1.668;1.666;1.667;1.667;1.668;1.667;1.667;1.667;1.667;1.668;1.668
;6;240p.120fps.mp4_scale_2_startup;1.927;1.908;1.947;1.946;1.902;1.932;1.916;1.936;1.921;1.896;1.908;1.894
;7;240p.120fps.mp4_scale_2_inclip;1.911;1.901;1.896;1.917;1.897;1.921;1.907;1.944;1.904;1.912;1.936;1.913
;8;480p.60fps.webm_scale_fullscreen_startup;11.675;11.587;11.539;11.454;11.723;11.410;11.629;11.410;11.454;11.498;11.540;11.540
;9;480p.60fps.webm_scale_fullscreen_inclip;11.304;11.238;11.370;11.300;11.364;11.368;11.237;11.238;11.434;11.238;11.304;11.368
;10;480p.60fps.webm_scale_1_startup;3.386;3.360;3.391;3.376;3.387;3.402;3.371;3.371;3.356;3.383;3.376;3.356
;11;480p.60fps.webm_scale_1_inclip;3.334;3.334;3.329;3.334;3.334;3.334;3.334;3.334;3.334;3.335;3.334;3.334
;12;480p.60fps.webm_scale_1.1_startup;3.363;3.363;3.368;3.356;3.356;3.379;3.364;3.360;3.360;3.356;3.363;3.356
;13;480p.60fps.webm_scale_1.1_inclip;3.329;3.334;3.329;3.334;3.333;3.334;3.334;3.334;3.340;3.335;3.329;3.335
;14;480p.60fps.webm_scale_2_startup;4.960;4.880;4.847;4.959;4.802;4.863;4.824;4.926;4.847;4.785;4.870;4.855
;15;480p.60fps.webm_scale_2_inclip;4.903;4.786;4.892;4.903;4.822;4.832;4.798;4.857;4.808;4.856;4.926;4.741
;16;1080p.60fps.mp4_scale_fullscreen_startup;14.638;14.495;14.496;14.710;14.781;14.853;14.639;14.637;14.707;14.637;14.711;14.636
;17;1080p.60fps.mp4_scale_fullscreen_inclip;13.795;13.798;13.893;13.702;13.799;13.607;13.798;13.705;13.896;13.896;13.896;14.088
;18;1080p.60fps.mp4_scale_1_startup;6.995;6.851;6.930;6.820;6.915;6.805;6.898;6.866;6.852;6.850;6.803;6.851
;19;1080p.60fps.mp4_scale_1_inclip;6.560;6.625;6.713;6.601;6.645;6.496;6.624;6.538;6.539;6.497;6.580;6.558
;20;1080p.60fps.mp4_scale_1.1_startup;7.354;7.230;7.195;7.300;7.266;7.283;7.196;7.249;7.230;7.230;7.212;7.264
;21;1080p.60fps.mp4_scale_1.1_inclip;6.969;7.222;7.018;6.993;7.045;6.970;6.970;6.807;7.118;6.969;6.997;6.972
;22;1080p.60fps.mp4_scale_2_startup;6.963;6.947;6.914;6.929;6.979;7.010;7.010245327102808;6.914;6.961;7.028;7.012;6.914
;23;1080p.60fps.mp4_scale_2_inclip;6.757;6.694;6.672;6.669;6.737;6.831;6.716;6.715;6.832;6.670;6.672;6.759
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== CanvasMark ===
* contact: :snorp, :milan, :jmaher
* source: https://github.com/kevinroast/CanvasMark
* type: [https://wiki.mozilla.org/Buildbot/Talos#Page_Load_Tests PageLoader]
* data: 5 cycles of the entire benchmark, each subtest will have 5 data points (see below)
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 4; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l522 source: test.py]
** score: [https://wiki.mozilla.org/Buildbot/Talos/Data#Canvasmark_metric canvasmark metric] on all summarized subtests
* '''Higher is better'''

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
|tcanvasmark
|
|}

These tests run the third-party [http://www.kevs3d.co.uk/dev/canvasmark/ CanvasMark] benchmark suite, which measures the browser's ability to render a variety of canvas animations at a smooth framerate as the scenes grow more complex.

Results are a score "based on the length of time the browser was able to maintain the test scene at greater than 30 FPS, multiplied by a weighting for the complexity of each test type".

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
1;Asteroids - Vectors;704;672;713;738;796
2;Asteroids - Bitmaps- shapes- text;1105;1139;1002;1122;1050
3;Asteroids - Shapes- shadows- blending;740;731;775;725;732
4;Arena5 - Vectors- shadows- bitmaps- text;841;679;865;942;873
5;Plasma - Maths- canvas shapes;583;583;557;604;632
6;3D Rendering - Maths- polygons- image transforms;340;445;374;425;425
7;Pixel blur - Math- getImageData- putImageData;1409;1408;1415;1508;1335
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== glterrain ===
* contact: :avih :jgilbert
* source: [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/webgl/benchmarks/terrain glterrain]]
* type: [https://wiki.mozilla.org/Buildbot/Talos#Page_Load_Tests PageLoader]
* data: we load the perftest.html page (which generates 4 metrics to track) 25 times, resulting in 4 sets of 25 data points
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 24; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l381 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 4 subtest results.

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
|glterrain
|Measures average frames interval while animating a simple WebGL scene
|}

This tests animates a simple WebGL scene (static textured landscape, one moving light source, rotating viewport) and measure the frames throughput (expressed as average interval) over 100 frames. It runs in ASAP mode (vsync off) and measures the same scene 4 times - for all combination of antialiasing and alpha. It reports the results as 4 values - one for each combination. Lower results are better.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;0.WebGL-terrain-alpha-no-AA-no;19.8189;20.57185;20.5069;21.09645;20.40045;20.89025;20.34285;20.8525;20.45845;20.6499;19.94505;20.05285;20.316049;19.46745;19.46135;20.63865;20.4789;19.97015;19.9546;20.40365;20.74385;20.828649;20.78295;20.51685;20.97069
1;1.WebGL-terrain-alpha-no-AA-yes;23.0464;23.5234;23.34595;23.40609;22.54349;22.0554;22.7933;23.00685;23.023649;22.51255;23.25975;23.65819;22.572249;22.9195;22.44325;22.95015;23.3567;23.02089;22.1459;23.04545;23.09235;23.40855;23.3296;23.18849;23.273249
2;2.WebGL-terrain-alpha-yes-AA-no;24.01795;23.889449;24.2683;24.34649;23.0562;24.02275;23.54819;24.1874;23.93545;23.53629;23.305149;23.62459;24.01589;24.06405;24.143449;23.998549;24.08205;24.26989;24.0736;24.2346;24.01145;23.7817;23.90785;24.7118;24.2834
3;3.WebGL-terrain-alpha-yes-AA-yes;25.91375;25.87005;25.64875;25.15615;25.5475;24.497449;24.56385;25.57529;25.54889;26.31559;24.143949;25.09895;24.75049;25.2087;25.52385;25.9017;25.4439;24.3495;25.9269;25.734449;26.4126;25.547449;25.667249;25.679349;25.9565
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== glvideo ===
* contact: :daoshengmu
* source: [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/webgl/benchmarks/video glvideo]]
* type: [https://wiki.mozilla.org/Buildbot/Talos#Page_Load_Tests PageLoader]
* data: 5 cycles of the entire benchmark, each subtest will have 5 data points (see below)
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 4; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l522 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 4 subtest results.

* '''Lower is better'''
* unit: ms/100 ticks

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
|glvideo
|WebGL video texture update with 1080p video. Measures mean tick time across 100 ticks.
|}

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;Mean tick time across 100 ticks: ;54.6916;49.0534;51.21645;51.239650000000005;52.44295
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== tp5o_scroll ===
* contact: :jmaher
* source: [https://people.mozilla.org/~jmaher/taloszips/zips/tp5n.zip tp5n.zip]
* type: [https://wiki.mozilla.org/Buildbot/Talos#Page_Load_Tests PageLoader]
* data: we load each of the 51 tp5o pages 12 times, resulting in 51 sets of 12 data points.
* '''To run it locally''', you'd need [[#tp5n_pages_set|tp5n.zip]].
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 11; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l470 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 51 subtest results.

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
|tp5o_scroll
|Measures average frames interval while scrolling the pages of the tp5o set
|}

This test is identical to tscrollx, but it scrolls the 50 pages of the tp5o set (rather than 6 synthetic pages which tscrollx scrolls). For each page, the test waits 500ms after the page load event fires, then iterates 100 scroll steps of 10px each (or until the bottom of the page is reached - whichever comes first), then reports the average frame interval.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;163.com/www.163.com/index.html;9.73;8.61;7.37;8.17;7.58;7.29;6.88;7.45;6.91;6.61;8.47;7.12
1;56.com/www.56.com/index.html;10.85;10.24;10.75;10.30;10.23;10.10;10.31;10.06;11.10;10.06;9.56;10.30
2;aljazeera.net/aljazeera.net/portal.html;9.23;7.15;7.50;7.26;7.73;7.05;7.14;7.66;7.23;7.93;7.26;7.18
3;amazon.com/www.amazon.com/Kindle-Wireless-Reader-Wifi-Graphite/dp/B002Y27P3M/507846.html;7.14;6.87;7.18;6.31;6.93;6.71;6.37;7.00;6.59;5.37;7.31;6.13
4;bbc.co.uk/www.bbc.co.uk/news/index.html;7.39;6.33;6.22;7.66;6.67;7.77;6.91;7.74;7.08;6.36;6.03;7.12
5;beatonna.livejournal.com/beatonna.livejournal.com/index.html;5.79;5.79;5.68;5.46;5.55;5.48;5.69;5.83;5.88;5.97;5.93;5.88
6;bild.de/www.bild.de/index.html;8.65;7.63;7.17;6.36;7.44;7.68;8.63;6.71;8.34;7.15;7.82;7.70
7;cgi.ebay.com/cgi.ebay.com/ALL-NEW-KINDLE-3-eBOOK-WIRELESS-READING-DEVICE-W-WIFI-/130496077314@pt=LH_DefaultDomain_0&hash=item1e622c1e02.html;7.12;6.81;7.22;6.98;7.05;5.68;7.15;6.54;7.31;7.18;7.82;7.77
8;chemistry.about.com/chemistry.about.com/index.html;6.76;6.17;6.41;6.88;5.67;5.47;6.83;6.28;6.16;6.81;6.21;6.75
9;chinaz.com/chinaz.com/index.html;10.72;7.99;7.33;7.10;7.85;8.62;8.39;6.72;6.26;6.65;8.14;7.78
10;cnn.com/www.cnn.com/index.html;7.73;6.80;6.08;8.27;9.24;7.81;7.69;7.05;8.17;7.70;7.90;6.81
11;dailymail.co.uk/www.dailymail.co.uk/ushome/index.html;6.37;8.28;7.19;8.00;8.09;7.43;6.90;7.24;7.77;7.29;7.38;6.14
12;dailymotion.com/www.dailymotion.com/us.html;9.53;9.80;9.29;9.03;9.10;8.64;8.62;8.71;8.77;9.81;9.64;8.96
13;digg.com/digg.com/news/story/New_logo_for_Mozilla_Firefox_browser.html;7.72;7.06;7.60;5.67;6.85;7.32;7.80;5.98;8.27;6.68;7.52;8.39
14;ezinearticles.com/ezinearticles.com/index.html@Migraine-Ocular---The-Eye-Migraines&id=4684133.html;7.14;7.11;8.09;7.17;6.87;7.12;7.65;7.74;7.26;7.36;6.91;6.95
15;globo.com/www.globo.com/index.html;6.71;7.91;5.83;7.34;7.75;8.00;7.73;7.85;7.03;6.42;8.43;8.11
16;google.com/www.google.com/search@q=mozilla.html;6.49;6.23;7.96;6.39;7.23;8.19;7.35;7.39;6.94;7.24;7.55;7.62
17;goo.ne.jp/goo.ne.jp/index.html;8.56;7.18;7.15;7.03;6.85;7.62;7.66;6.99;7.84;7.51;7.23;7.18
18;guardian.co.uk/www.guardian.co.uk/index.html;7.32;7.62;8.18;7.62;7.83;8.08;7.60;8.17;8.47;7.54;7.92;8.09
19;homeway.com.cn/www.hexun.com/index.html;10.18;8.75;8.83;8.64;8.98;8.07;7.76;9.29;8.05;7.55;8.91;7.78
20;huffingtonpost.com/www.huffingtonpost.com/index.html;8.38;7.17;7.03;6.83;6.49;6.47;6.69;7.08;6.81;7.29;7.13;7.70
21;ifeng.com/ifeng.com/index.html;12.45;8.65;8.75;7.56;8.26;7.71;8.04;7.45;7.83;7.14;8.38;7.68
22;imdb.com/www.imdb.com/title/tt1099212/index.html;8.53;5.65;6.94;7.18;6.10;7.57;6.26;8.34;8.16;7.29;7.62;8.51
23;imgur.com/imgur.com/gallery/index.html;8.10;7.20;7.50;7.88;7.27;6.97;8.13;7.14;7.59;7.39;8.01;8.82
24;indiatimes.com/www.indiatimes.com/index.html;8.00;6.74;7.37;8.52;7.03;8.45;7.08;8.47;9.26;7.89;7.17;6.74
25;mail.ru/mail.ru/index.html;7.64;9.50;9.47;7.03;6.45;6.24;8.03;6.72;7.18;6.39;6.25;6.25
26;mashable.com/mashable.com/index.html;7.97;8.03;6.10;7.80;7.91;7.26;7.49;7.45;7.60;7.08;7.63;7.36
27;media.photobucket.com/media.photobucket.com/image/funny%20gif/findstuff22/Best%20Images/Funny/funny-gif1.jpg@o=1.html;290.00;195.00;217.00;199.00;204.00;196.00;198.00;206.00;209.00;208.00;192.00;196.00
28;myspace.com/www.myspace.com/albumart.html;14.40;13.45;13.29;13.62;13.42;14.15;13.86;14.34;14.69;14.10;13.82;14.13
29;naver.com/www.naver.com/index.html;9.15;8.31;9.40;9.89;7.29;8.43;8.87;8.77;8.96;8.24;8.16;8.21
30;noimpactman.typepad.com/noimpactman.typepad.com/index.html;7.27;7.14;7.70;7.86;7.43;6.95;7.30;7.58;7.51;7.95;7.43;7.05
31;page.renren.com/page.renren.com/index.html;7.94;8.13;6.76;7.77;6.93;6.60;7.62;7.61;6.88;7.56;7.55;7.48
32;people.com.cn/people.com.cn/index.html;11.92;9.22;8.49;8.55;8.34;8.49;6.91;9.92;8.69;8.63;7.69;9.34
33;rakuten.co.jp/www.rakuten.co.jp/index.html;11.10;7.13;8.68;7.85;8.37;7.91;6.74;8.27;8.55;8.93;7.15;9.02
34;reddit.com/www.reddit.com/index.html;6.38;7.95;6.84;7.04;6.96;7.15;8.05;7.71;8.13;7.13;6.60;7.53
35;reuters.com/www.reuters.com/index.html;7.51;7.25;6.60;6.98;7.41;6.45;7.61;7.46;6.11;7.15;7.05;6.94
36;slideshare.net/www.slideshare.net/jameswillamor/lolcats-in-popular-culture-a-historical-perspective.html;7.20;6.32;6.80;6.87;6.29;6.45;7.18;6.92;6.57;7.41;7.08;6.51
37;sohu.com/www.sohu.com/index.html;11.72;9.64;8.85;7.12;7.96;9.14;7.76;8.19;7.14;7.68;8.08;7.24
38;spiegel.de/www.spiegel.de/index.html;7.24;7.30;6.64;7.01;6.74;6.70;6.36;6.84;7.86;7.08;7.12;7.40
39;stackoverflow.com/stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered.html;7.39;5.88;7.22;6.51;7.12;6.51;6.46;6.53;6.63;6.54;6.48;6.80
40;store.apple.com/store.apple.com/us@mco=Nzc1MjMwNA.html;6.23;7.17;7.39;8.98;7.99;8.03;9.12;8.37;8.56;7.61;8.06;7.55
41;thepiratebay.org/thepiratebay.org/top/201.html;9.08;8.93;8.09;7.49;7.30;7.80;7.54;7.65;7.91;7.53;8.37;8.04
42;tudou.com/www.tudou.com/index.html;10.06;9.38;8.68;7.37;8.57;9.11;8.20;7.91;8.78;9.64;8.11;8.47
43;uol.com.br/www.uol.com.br/index.html;9.04;9.49;9.48;9.31;8.68;8.41;9.16;8.91;9.49;8.37;9.77;8.73
44;w3.org/www.w3.org/standards/webdesign/htmlcss.html;6.62;5.98;6.87;6.47;7.22;6.05;6.42;6.50;7.47;7.18;5.82;7.11
45;wsj.com/online.wsj.com/home-page.html;7.49;8.57;6.84;8.12;7.60;7.24;8.16;8.22;6.81;8.28;8.11;8.58
46;xinhuanet.com/xinhuanet.com/index.html;13.66;9.21;10.09;9.56;8.99;10.29;10.24;8.91;11.23;10.82;9.64;10.11
47;xunlei.com/xunlei.com/index.html;8.99;8.16;8.82;8.37;7.01;8.48;7.98;8.69;8.10;8.10;7.10;6.41
48;yelp.com/www.yelp.com/biz/alexanders-steakhouse-cupertino.html;8.18;7.45;7.01;8.14;7.12;7.82;8.24;7.13;7.00;6.41;6.85;7.31
49;youku.com/www.youku.com/index.html;12.21;10.29;10.37;10.34;8.40;9.82;9.23;9.91;9.64;9.91;8.90;10.23
50;youtube.com/www.youtube.com/music.html;9.90;9.06;9.29;9.17;8.85;8.77;9.83;9.21;9.29;10.09;9.69;8.64
</pre>
|}

==== Possible regression causes ====
Some examples of things that cause regressions in this test are:
* Increased displayport size (which causes a larger display list to be built)
* Slowdown in the building of display list
* Slowdown in rasterization of content

=== tp5 ===
* contact: :jmaher
* source: [https://people.mozilla.org/~jmaher/taloszips/zips/tp5n.zip tp5n.zip]
* type: [https://wiki.mozilla.org/Buildbot/Talos#Page_Load_Tests PageLoader]
* data: we load each of the 51 tp5o pages 25 times, resulting in 51 sets of 25 data points.
* '''To run it locally''', you'd need [[#tp5n_pages_set|tp5n.zip]].
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] '''5''' data points, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 20; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l449 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 51 subtest results.

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
|tp5o
|tp5 with limited pageset (48 pages as others have too much noise)
|}

Tests the time it takes Firefox to load the [https://people.mozilla.org/~jmaher/taloszips/zips/tp5n.zip tp5 web page test set]. The web set was culled from the Alexa top 500 April 8th, 2011 and consists of 51 pages.

Here are the broad steps we use to create the test set:
# Take the Alexa top 500 sites list
# Remove all sites with questionable or explicit content
# Remove duplicate site (for ex. many Google search front pages)
# Manually select to keep interesting pages (such as pages in different locales)
# Select a more representative page from any site presenting a simple search/login/etc. page
# Deal with Windows 255 char limit for cached pages
# Limit test set to top 100 pages

Note that the above steps did not eliminate all outside network access so we had to take further action to scrub all the pages so that there are 0 outside network accesses (this is done so that the tp test is as deterministic measurement of our rendering/layout/paint process as possible).

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;163.com/www.163.com/index.html;1035;512;542;519;505;514;551;513;554;793;487;528;528;498;503;530;527;490;521;535;521;496;498;564;520
1;56.com/www.56.com/index.html;1081;583;580;577;597;580;623;558;572;592;598;580;564;583;596;600;579;580;566;573;566;581;571;600;586
2;aljazeera.net/aljazeera.net/portal.html;688;347;401;382;346;362;347;372;337;345;365;337;380;338;355;360;356;366;367;352;350;366;346;375;382
3;amazon.com/www.amazon.com/Kindle-Wireless-Reader-Wifi-Graphite/dp/B002Y27P3M/507846.html;1392;878;901;852;886;867;877;864;862;877;866;888;3308;870;863;869;873;850;851;850;857;873;869;860;855
4;bbc.co.uk/www.bbc.co.uk/news/index.html;455;271;272;271;279;289;276;285;277;291;281;286;278;286;274;285;276;285;287;286;276;288;279;272;278
5;beatonna.livejournal.com/beatonna.livejournal.com/index.html;290;123;123;129;120;121;124;125;119;125;120;150;121;147;121;121;113;121;119;122;117;112;127;117;139
6;bild.de/www.bild.de/index.html;1314;937;946;931;922;918;920;937;934;930;947;928;936;933;933;928;930;941;951;946;947;938;925;939;938
7;cgi.ebay.com/cgi.ebay.com/ALL-NEW-KINDLE-3-eBOOK-WIRELESS-READING-DEVICE-W-WIFI-/130496077314@pt=LH_DefaultDomain_0&hash=item1e622c1e02.html;495;324;330;328;321;308;315;308;321;313;327;330;317;339;333;322;312;370;336;327;310;312;312;355;330
8;chemistry.about.com/chemistry.about.com/index.html;238;156;156;154;158;161;152;151;152;167;179;152;154;156;161;161;157;167;151;167;154;149;178;153;160
9;chinaz.com/chinaz.com/index.html;347;223;255;234;245;233;264;234;244;228;260;224;258;223;280;220;243;225;251;226;258;232;258;232;247
10;cnn.com/www.cnn.com/index.html;551;384;436;394;391;375;371;407;371;374;398;372;368;388;376;380;386;377;363;383;384;370;388;381;374
11;dailymail.co.uk/www.dailymail.co.uk/ushome/index.html;984;606;551;561;545;542;576;564;543;560;566;557;561;544;545;576;548;539;568;567;557;560;545;544;578
12;dailymotion.com/www.dailymotion.com/us.html;473;271;286;272;285;288;290;290;280;268;286;269;287;275;289;282;293;287;304;261;289;284;281;277;286
13;digg.com/digg.com/news/story/New_logo_for_Mozilla_Firefox_browser.html;410;321;304;303;322;300;319;321;320;306;323;313;312;305;312;338;317;338;301;325;297;302;309;305;300
14;ezinearticles.com/ezinearticles.com/index.html@Migraine-Ocular---The-Eye-Migraines&id=4684133.html;234;177;163;163;186;176;185;175;167;156;162;199;163;190;173;181;175;178;165;159;182;170;183;169;158
15;globo.com/www.globo.com/index.html;684;468;466;485;482;445;433;467;467;450;487;466;440;484;444;451;511;443;429;469;468;430;485;459;447
16;google.com/www.google.com/search@q=mozilla.html;150;100;102;101;97;104;99;116;107;100;98;137;102;102;99;106;98;112;100;102;105;104;107;96;100
17;goo.ne.jp/goo.ne.jp/index.html;328;125;132;132;143;121;122;120;132;145;166;139;144;125;128;152;128;145;130;132;154;126;142;133;139
18;guardian.co.uk/www.guardian.co.uk/index.html;462;311;296;322;309;305;303;288;301;308;301;304;319;309;295;305;294;308;304;322;310;314;302;303;292
19;homeway.com.cn/www.hexun.com/index.html;584;456;396;357;417;374;376;406;363;392;400;378;378;402;390;373;398;393;366;385;383;361;418;386;351
20;huffingtonpost.com/www.huffingtonpost.com/index.html;811;609;575;596;568;585;589;571;568;600;571;588;585;570;574;616;576;564;598;594;589;590;572;572;612
21;ifeng.com/ifeng.com/index.html;829;438;478;462;448;465;469;470;429;463;465;432;482;444;476;453;460;476;461;484;467;510;447;477;443
22;imdb.com/www.imdb.com/title/tt1099212/index.html;476;337;358;332;414;379;344;420;354;363;387;345;358;371;341;385;359;379;353;349;392;349;358;378;347
23;imgur.com/imgur.com/gallery/index.html;419;205;224;231;207;222;206;231;204;219;209;210;210;208;202;215;203;210;203;212;218;219;202;224;230
24;indiatimes.com/www.indiatimes.com/index.html;530;339;348;384;376;381;353;350;403;333;356;393;350;328;393;329;389;346;394;349;382;332;409;327;354
25;mail.ru/mail.ru/index.html;500;256;308;251;271;270;270;246;273;252;279;249;301;252;251;256;271;246;267;254;265;248;277;247;275
26;mashable.com/mashable.com/index.html;699;497;439;508;440;448;512;446;431;500;445;427;495;455;458;499;440;432;522;443;447;488;445;461;489
27;media.photobucket.com/media.photobucket.com/image/funny%20gif/findstuff22/Best%20Images/Funny/funny-gif1.jpg@o=1.html;294;203;195;189;213;186;195;186;204;188;190;220;204;202;195;204;192;204;191;187;204;199;191;192;211
28;myspace.com/www.myspace.com/albumart.html;595;446;455;420;433;425;416;429;452;411;435;439;389;434;418;402;422;426;396;438;423;391;434;438;395
29;naver.com/www.naver.com/index.html;626;368;338;386;342;377;371;352;379;348;362;357;359;354;386;338;394;330;326;372;345;392;336;336;368
30;noimpactman.typepad.com/noimpactman.typepad.com/index.html;431;333;288;292;285;313;277;289;282;292;276;293;270;294;289;281;275;302;285;290;280;285;278;284;283
31;page.renren.com/page.renren.com/index.html;373;232;228;228;213;227;224;227;226;216;234;226;230;212;213;221;224;230;212;218;217;221;212;222;230
32;people.com.cn/people.com.cn/index.html;579;318;305;339;307;341;325;326;307;309;315;314;318;317;321;309;307;299;312;313;305;326;318;384;310
33;rakuten.co.jp/www.rakuten.co.jp/index.html;717;385;371;388;381;348;394;358;396;368;343;386;348;388;393;388;360;339;398;357;392;378;395;386;367
34;reddit.com/www.reddit.com/index.html;340;254;248;255;241;241;248;275;251;250;250;252;243;274;240;269;254;249;242;257;271;253;243;278;252
35;reuters.com/www.reuters.com/index.html;513;404;355;358;379;343;354;385;379;354;418;363;342;412;355;351;402;375;354;400;362;355;380;373;336
36;slideshare.net/www.slideshare.net/jameswillamor/lolcats-in-popular-culture-a-historical-perspective.html;397;279;270;283;285;283;291;286;289;284;275;281;288;284;280;279;290;301;290;270;292;282;289;267;278
37;sohu.com/www.sohu.com/index.html;727;414;479;414;431;485;418;440;488;431;432;464;442;407;488;435;416;465;445;414;480;416;403;463;429
38;spiegel.de/www.spiegel.de/index.html;543;430;391;380;440;387;375;430;380;397;415;383;434;420;384;399;421;392;384;418;388;380;427;403;392
39;stackoverflow.com/stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered.html;503;377;356;438;370;388;409;367;366;407;375;363;393;360;363;396;376;391;426;363;378;408;400;359;408
40;store.apple.com/store.apple.com/us@mco=Nzc1MjMwNA.html;488;327;344;343;333;329;328;348;361;342;362;332;389;333;382;331;382;343;405;343;326;325;329;323;340
41;thepiratebay.org/thepiratebay.org/top/201.html;412;274;317;260;256;269;266;261;258;289;245;284;256;277;251;302;276;307;268;268;247;285;260;271;257
42;tudou.com/www.tudou.com/index.html;522;304;281;283;287;285;288;307;279;288;282;303;292;288;290;287;311;271;279;274;294;272;290;269;290
43;uol.com.br/www.uol.com.br/index.html;668;387;450;411;395;452;386;431;452;394;385;436;413;414;440;401;412;439;408;430;426;415;382;433;387
44;w3.org/www.w3.org/standards/webdesign/htmlcss.html;225;143;129;151;181;141;147;137;159;179;142;153;136;139;191;140;151;143;141;181;140;154;142;143;183
45;wsj.com/online.wsj.com/home-page.html;634;466;512;463;467;507;461;432;492;494;491;507;466;477;495;455;451;495;461;463;494;468;444;497;442
46;xinhuanet.com/xinhuanet.com/index.html;991;663;727;659;647;639;644;656;666;658;670;648;676;653;652;654;641;636;664;668;655;657;646;674;633
47;xunlei.com/xunlei.com/index.html;802;625;624;636;641;652;659;642;623;635;628;606;667;688;683;694;672;640;628;620;653;626;633;654;643
48;yelp.com/www.yelp.com/biz/alexanders-steakhouse-cupertino.html;752;475;502;472;477;512;489;478;501;472;454;517;487;474;521;467;450;513;491;464;536;507;455;511;481
49;youku.com/www.youku.com/index.html;844;448;498;441;417;497;478;439;467;436;447;465;438;461;466;446;452;496;457;446;486;449;467;499;442
50;youtube.com/www.youtube.com/music.html;443;338;253;289;238;296;254;290;242;302;237;290;253;305;253;293;251;311;244;293;255;291;246;316;249
</pre>
|}

==== File IO ====

===== Possible regression causes =====
* '''nonmain_startup_fileio opt (with or without e10s) windows7-32''' – {{bug|1274018}} This test seems to consistently report a higher result for mozilla-central compared to Try even for an identical revision due to extension signing checks. In other words, if you are comparing Try and Mozilla-Central you may see a false-positive regression on perfherder. Graphs: [https://treeherder.mozilla.org/perf.html#/graphs?timerange=604800&series=%5Bmozilla-central,e5f5eaa174ef22fdd6b6e150e8c450aa827c2ff6,1,1%5D&series=%5Btry,e5f5eaa174ef22fdd6b6e150e8c450aa827c2ff6,1,1%5D non-e10s] [https://treeherder.mozilla.org/perf.html#/graphs?series=%5B%22mozilla-central%22,%222f3af3833d55ff371ecf01c41aeee1939ef3a782%22,1,1%5D&series=%5B%22try%22,%222f3af3833d55ff371ecf01c41aeee1939ef3a782%22,1,1%5D&timerange=604800 e10s]

==== Private Bytes ====

A memory metric tracked during tp4 test runs. This metric is sampled every 20 seconds.

For windows, a [https://technet.microsoft.com/en-us/library/cc780836%28WS.10%29.aspx description from Microsoft TechNet].

===== Possible regression causes =====
* Changing JavaScript GC policies or tuning parameters.
* If you fix a regression for this test and have some tips to share, this is a good place for them.

==== RSS (Resident Set Size)====

A memory metric tracked during tp5 test runs. This metric is sampled every 20 seconds. This metric is collected on linux/mac only.

[https://en.wikipedia.org/wiki/Resident_set_size Description from wikipedia].

===== Possible regression causes =====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

==== Xres (X Resource Monitoring) ====

A memory metric tracked during tp5 test runs. This metric is sampled every 20 seconds. This metric is collected on linux only.

[https://linux.die.net/man/3/xres xres man page].

===== Possible regression causes =====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

==== Working Set (tp5_memset) ====

A memory metric tracked during tp5 test runs. This metric is sampled every 20 seconds. This metric is collected on windows only. [https://technet.microsoft.com/en-us/library/cc780836%28WS.10%29.aspx Description from Microsoft TechNet].

===== Possible regression causes =====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

==== Modified Page List Bytes ====

A memory metric tracked during tp5 test runs. This metric is sampled every 20 seconds. This metric is collected on Windows7 only. [https://msdn.microsoft.com/en-us/library/aa965225%28VS.85%29.aspx Description from Microsoft MSDN].

===== Possible regression causes =====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

==== % CPU ====

Cpu usage tracked during tp5 test runs. This metric is sampled every 20 seconds. This metric is collected on windows only.

===== Possible regression causes =====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

==== Responsiveness ====
contact: :jimm, :jmaher

Measures the delay for the event loop to process a [[Performance/Snappy#Current Infrastructure|tracer event]]. For more details, see {{bug|631571}}.

The score on this benchmark is proportional to the sum of squares of all event delays that exceed a 20ms threshold. Lower is better.

We collect 8000+ data points from the browser during the test and apply [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/output.py#l95 this formula] to the results:
<pre>
return sum([float(x)*float(x) / 1000000.0 for x in val_list])
</pre>

===== Possible regression causes =====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== ts_paint ===

* contact: :mak, :jimm, :jmaher
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/startup_test/tspaint_test.html tspaint_test.html]
* Perfomatic: "Ts, Paint"
* type: Startup
* data: 20 times we start the browser and time how long it takes to paint the startup test page, resulting in 1 set of 20 data points.
* summarization:
** subtest: identical to suite
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 19 data points; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l135 source: test.py]

Starts the browser to display tspaint_test.html with the start time in the url, waits for [[Buildbot/Talos/Tests#Paint_Tests|MozAfterPaint and onLoad]] to fire, then records the end time and calculates the time to startup.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
[1666.0, 1195.0, 1139.0, 1198.0, 1248.0, 1224.0, 1213.0, 1194.0, 1229.0, 1196.0, 1191.0, 1230.0, 1247.0, 1169.0, 1217.0, 1184.0, 1196.0, 1192.0, 1224.0, 1192.0]
</pre>
|}

==== Possible regression causes ====
* (and/or maybe tpaint?) will regress if a new <panel> element is added to the browser window (e.g. browser.xul) and it's frame gets created. Fix this by ensuring it's display:none by default.

=== tsvgx ===
* contact: :jwatt, :jmaher, :avih
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/svgx svgx]
* type: PageLoader
* data: we load the 7 svg pages 25 times, resulting in 7 sets of 25 data points
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] '''5''' data points, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 20; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l623 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 7 subtest results.

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
|tsvgx
|SVG-ASAP
|[https://groups.google.com/d/topic/mozilla.dev.platform/RICw5SJhNMo/discussion Replacing tscroll,tsvg with tscrollx,tsvgx]
|}

An svg-only number that measures SVG rendering performance, with animations or iterations of rendering. This is an ASAP test -- i.e. it iterates in unlimited frame-rate mode thus reflecting the maximum rendering throughput of each test. The reported value is the overall duration the sequence/animation took to complete. To turn on ASAP mode, we set these preferences:
preferences = {'layout.frame_rate': 0, 'docshell.event_starvation_delay_hint': 1}

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;hixie-001.xml;562;555;508;521;522;520;499;510;492;514;502;504;500;521;510;506;511;505;495;517;520;512;503;504;502
1;hixie-002.xml;510;613;536;530;536;522;498;505;500;504;498;529;498;509;493;512;501;506;504;499;496;505;508;511;503
2;hixie-003.xml;339;248;242;261;250;241;240;248;258;244;235;240;247;248;239;247;241;245;242;245;251;239;241;240;237
3;hixie-004.xml;709;540;538;536;540;536;552;539;535;535;543;533;536;535;545;537;537;537;537;539;538;535;536;538;536
4;hixie-005.xml;3096;3086;3003;3809;3213;3323;3143;3313;3192;3203;3225;3048;3069;3101;3189;3251;3172;3122;3266;3183;3159;3076;3014;3237;3100
5;hixie-006.xml;5586;5668;5565;5666;5668;5728;5886;5534;5484;5607;5678;5577;5745;5753;5532;5585;5506;5516;5648;5778;5894;5994;5794;5852;5810
6;hixie-007.xml;1823;1743;1739;1743;1744;1787;1802;1788;1782;1766;1787;1750;1748;1788;1766;1779;1767;1794;1758;1768;1781;1773;1765;1798;1805
</pre>
|}

==== Possible regression causes ====
* Did you change the dimensions of the content area? Even a little? The tsvgx test seems to be sensitive to changes like this. See {{bug|1375479}}, for example. Usually, these sorts of "regressions" aren't real regressions - they just mean that we need to re-baseline our expectations from the test.

=== tsvg_static ===
* contact: :jwatt, :jmaher, :dholbert, :neerja
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/svg_static/ svg_static]
* type: PageLoader
* data: we load the 5 svg pages 25 times, resulting in 5 sets of 25 data points
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] '''5''' data points, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 20; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l623 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 5 subtest results.

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
|tsvg_static
|An svg-only number that measures SVG rendering performance of some complex (but static) SVG content.
|}

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;gearflowers.svg;262;184;184;198;197;187;181;186;177;192;196;194;194;186;195;190;237;193;188;182;188;196;191;194;184
1;composite-scale.svg;69;52;48;49;57;51;52;87;52;49;49;51;58;53;64;57;49;65;67;58;53;59;56;68;50
2;composite-scale-opacity.svg;72;53;91;54;51;58;60;46;51;57;59;58;66;70;57;61;47;51;76;65;52;65;64;64;63
3;composite-scale-rotate.svg;70;76;89;62;62;78;57;77;79;82;74;56;61;79;73;64;75;74;81;82;76;58;77;61;62
4;composite-scale-rotate-opacity.svg;91;60;67;84;62;66;78;69;65;68;62;73;68;63;64;71;79;77;63;80;85;65;82;76;81
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== tsvgr_opacity ===
* contact: :jwatt, :jmaher, :avih
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/svg_opacity/svg_opacity.manifest]
* type: PageLoader
* data: we load the 2 svg opacity pages 25 times, resulting in 2 sets of 25 data points
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] '''5''' data points, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 20; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l623 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 2 subtest results.

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
|tsvgr_opacity
|[[#Row_Major_vs._Column_Major|Row Major]] and 25 cycles/page.
|}

Renders many semi-transparent, partially overlapping SVG rectangles, and measures time to completion of this rendering.

Note that this test also tends to reflect changes in network efficiency and navigation bar rendering issues:

* Most of the page load tests measure from before the location is changed, until onload + mozafterpaint, therefore any changes in chrome performance from the location change, or network performance (the pages load from a local web server) would affect page load times. SVG opacity is rather quick by itself, so any such chrome/network/etc performance changes would affect this test more than other page load tests (relatively, in percentages).

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;big-optimizable-group-opacity-2500.svg;170;171;205;249;249;244;192;252;192;431;182;250;189;249;151;168;209;194;247;250;193;250;255;247;247
1;small-group-opacity-2500.svg;585;436;387;441;512;438;440;380;443;391;450;386;459;383;445;388;450;436;485;443;383;438;528;444;441
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== tpaint ===
* contact: :jimm, :jmaher
* source: [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/startup_test/tpaint.html tpaint-window.html]]
* type: Startup
* data: we load the tpaint test window 20 times, resulting in 1 set of 20 data points.
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] '''5''' data points, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 15; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l190 source: test.py]
** suite: identical to subtest

{| cellspacing="1" cellpadding="1" border="1"
|-
|Talos test name
|Description
|-
|tpaint
|twinopen but measuring the time after we receive the [[Buildbot/Talos/Tests#Paint_Tests|MozAfterPaint and OnLoad event]].
|}

Tests the amount of time it takes the open a new window. This test does not include startup time. Multiple test windows are opened in succession, results reported are the average amount of time required to create and display a window in the running instance of the browser. (Measures ctrl-n performance.)

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
[209.219, 222.180, 225.299, 225.970, 228.090, 229.450, 230.625, 236.315, 239.804, 242.795, 244.5, 244.770, 250.524, 251.785, 253.074, 255.349, 264.729, 266.014, 269.399, 326.190]
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== Dromaeo Tests ===

Dromaeo suite of tests for JavaScript performance testing. See the [https://wiki.mozilla.org/Dromaeo Dromaeo wiki] for more information.

This suite is divided into several sub-suites.

Each sub-suite is divided into tests, and each test is divided into sub-tests. Each sub-test takes some (in theory) fixed piece of work and measures how many times that piece of work can be performed in one second. The score for a test is then the geometric mean of the runs/second numbers for its sub-tests. The score for a sub-suite is the geometric mean of the scores for its tests.

==== Dromaeo CSS ====
* contact: :bz, :jmaher
* source: [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/dromaeo css.manifest]]
* type: PageLoader
* reporting: speed in test runs per second (higher is better)
* data: Dromaeo has 6 subtests which run internal benchmarks, each benchmark reports about 180 raw data points each
summarization:
* subtest: Dromaeo is a custom benchmark which has a lot of micro tests inside each subtest, because of this we use a custom [https://wiki.mozilla.org/Buildbot/Talos/Data#dromaeo dromaeo filter] to summarize the subtest. Each micro test produces 5 data points and for each 5 data points we take the mean, leaving 36 data points to represent the subtest (assuming 180 points). These 36 micro test means, are then run through a geometric_mean to produce a single number for the dromaeo subtest. [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l527 source: filter.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 6 subtest results.

Each page in the manifest is part of the dromaeo css benchmark. Each page measures the performance of searching the DOM for nodes matching various CSS selectors, using different libraries for the selector implementation (jQuery, Dojo, Mootools, ExtJS, Prototype, and Yahoo UI).

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;dojo.html;2209.83;2269.68;2275.47;2278.83;2279.81;4224.43;4344.96;4346.74;4428.69;4459.82;4392.80;4396.38;4412.54;4414.34;4415.62;3909.94;4027.96;4069.08;4099.63;4099.94;4017.70;4018.96;4054.25;4068.74;4081.31;3825.10;3984.20;4053.23;4074.59;4106.63;3893.88;3971.80;4031.15;4046.68;4048.31;3978.24;4010.16;4046.66;4051.68;4056.37;4189.50;4287.98;4390.98;4449.89;4450.20;4536.23;4557.82;4588.40;4662.58;4664.42;4675.51;4693.13;4743.72;4758.12;4764.67;4138.00;4251.60;4346.22;4410.12;4417.23;4677.53;4702.48;4714.62;4802.59;4805.33;4445.07;4539.91;4598.93;4605.45;4618.79;4434.40;4543.09;4618.56;4683.98;4689.51;4485.26;4496.75;4511.23;4600.86;4602.08;4567.52;4608.33;4615.56;4619.31;4622.79;3469.44;3544.11;3605.80;3647.74;3658.56;3101.88;3126.41;3147.73;3159.92;3170.73;3672.28;3686.40;3730.74;3748.89;3753.59;4411.71;4521.50;4633.98;4702.72;4708.76;3626.62;3646.71;3713.07;3713.13;3718.91;3846.17;3846.25;3913.61;3914.63;3916.22;3982.88;4112.98;4132.26;4194.92;4201.54;4472.64;4575.22;4644.74;4645.42;4665.51;4120.13;4142.88;4171.29;4208.43;4211.03;4405.36;4517.89;4537.50;4637.77;4644.28;4548.25;4581.20;4614.54;4658.42;4671.09;4452.78;4460.09;4494.06;4521.30;4522.37;4252.81;4350.72;4364.93;4441.40;4492.78;4251.34;4346.70;4355.00;4358.89;4365.72;4494.64;4511.03;4582.11;4591.79;4592.36;4207.54;4308.94;4309.14;4406.71;4474.46
1;ext.html;479.65;486.21;489.61;492.94;495.81;24454.14;33580.33;34089.15;34182.83;34186.15;34690.83;35050.30;35051.30;35071.65;35099.82;5758.22;5872.32;6389.62;6525.38;6555.57;8303.96;8532.96;8540.91;8544.00;8571.49;8360.79;8408.79;8432.96;8447.28;8447.83;5817.71;5932.67;8371.83;8389.20;8643.44;7983.80;8073.27;8073.84;8076.48;8078.15;24596.00;32518.84;32787.34;32830.51;32861.00;2220.87;2853.84;3333.53;3345.17;3445.47;24785.75;24971.75;25044.25;25707.61;25799.00;2464.69;2481.89;2527.57;2534.65;2534.92;217793.00;219347.90;219495.00;220059.00;297168.00;40556.19;53062.47;54275.73;54276.00;54440.37;50636.75;50833.49;50983.49;51028.49;51032.74;10746.36;10972.45;11450.37;11692.18;11797.76;8402.58;8415.79;8418.66;8426.75;8428.16;16768.75;16896.00;16925.24;16945.58;17018.15;7047.68;7263.13;7313.16;7337.38;7383.22;713.88;723.72;751.47;861.35;931.00;25454.36;25644.90;25801.87;25992.61;25995.00;819.89;851.23;852.00;886.59;909.89;14325.79;15064.92;15240.39;15431.23;15510.61;452382.00;458194.00;458707.00;459226.00;459601.00;45699.54;46244.54;46270.54;46271.54;46319.00;1073.94;1080.66;1083.35;1085.84;1087.74;26622.33;27807.58;27856.72;28040.58;28217.86;37229.81;37683.81;37710.81;37746.62;37749.81;220386.00;222903.00;240808.00;247394.00;247578.00;25567.00;25568.49;25610.74;25650.74;25710.23;26466.21;28718.71;36175.64;36529.27;36556.00;26676.00;30757.69;31965.84;34521.83;34622.65;32791.18;32884.00;33194.83;33720.16;34192.66;32150.36;32520.02;32851.18;32947.18;33128.01;29472.85;30214.09;30708.54;30999.23;32879.51;23822.88;23978.28;24358.88;24470.88;24515.51
2;jquery.html;285.42;288.57;292.66;293.75;294.14;10313.00;10688.20;13659.11;13968.65;14003.93;13488.39;13967.51;13980.79;14545.13;15059.77;4361.37;4488.35;4489.44;4492.24;4496.69;3314.32;3445.07;4412.51;5020.75;5216.66;5113.49;5136.56;5141.31;5143.87;5156.28;5055.95;5135.02;5138.64;5215.82;5226.48;4550.98;4551.59;4553.07;4557.77;4559.16;18339.63;18731.53;18738.63;18741.16;18806.15;1474.99;1538.31;1557.52;1703.67;1772.16;12209.94;12335.44;12358.32;12516.50;12651.94;1520.94;1522.62;1541.37;1584.71;1642.50;57533.00;59169.41;59436.11;59758.70;59872.40;8669.13;8789.34;8994.37;9016.05;9064.95;11047.39;11058.39;11063.78;11077.89;11082.78;6401.81;6426.26;6504.35;6518.25;6529.61;6250.22;6280.65;6304.59;6318.91;6328.72;5144.28;5228.40;5236.21;5271.26;5273.79;1398.91;1450.05;1456.39;1494.66;1519.42;727.85;766.62;844.35;858.49;904.87;9912.55;10249.54;14936.71;16566.50;16685.00;378.04;381.34;381.44;385.67;387.23;5362.60;5392.78;5397.14;5497.12;5514.83;213309.00;318297.00;320682.00;322681.00;322707.00;56357.44;67892.66;68329.66;68463.32;69506.00;418.91;424.49;425.19;425.28;426.40;9363.39;9559.95;9644.00;9737.07;9752.80;33170.83;33677.33;34950.83;35607.47;35765.82;44079.34;44588.55;45396.00;46309.00;46427.30;6302.87;6586.51;6607.08;6637.44;6642.17;9776.17;9790.46;9931.90;10391.79;10392.43;8739.26;8838.38;8870.20;8911.50;8955.15;8422.83;8786.21;8914.00;9135.82;9145.36;8945.28;9028.37;9035.23;9116.64;9137.86;6433.90;6688.73;6822.11;6830.08;6833.90;8575.23;8599.87;8610.91;8655.65;9123.91
3;mootools.html;1161.69;1333.31;1425.89;1500.37;1557.37;6706.93;7648.46;8020.04;8031.36;8049.64;7861.80;7972.40;7978.12;7993.32;7993.88;1838.83;1862.93;1864.11;1866.28;1866.71;1909.93;1921.83;1928.53;1954.07;1969.98;1808.68;1820.01;1821.30;1825.92;1826.91;1849.07;1904.99;1908.26;1911.24;1912.50;1856.86;1871.78;1873.72;1878.54;1929.57;6506.67;6752.73;7799.22;7830.41;7855.18;4117.18;4262.42;4267.30;4268.27;4269.62;2720.56;2795.36;2840.08;2840.79;2842.62;699.12;703.75;774.36;791.73;798.18;11096.22;11126.39;11132.72;11147.16;11157.44;3934.33;4067.37;4140.94;4149.75;4150.38;9042.82;9077.46;9083.55;9084.41;9086.41;4431.47;4432.84;4437.33;4438.40;4440.44;3935.67;3937.31;3937.43;3940.53;3976.68;3247.17;3307.90;3319.90;3323.32;3330.60;1001.90;1016.87;1021.12;1021.67;1022.05;1016.34;1019.09;1036.62;1056.81;1057.76;7345.56;7348.56;7391.89;7393.85;7406.30;374.27;392.53;394.73;397.28;398.26;5588.58;5653.21;5655.07;5659.15;5660.66;9775.41;9860.51;9938.40;9959.85;9968.45;9733.42;9904.31;9953.05;9960.55;9967.20;6399.26;6580.11;7245.93;7336.96;7386.78;7162.00;7245.49;7249.38;7250.75;7304.63;8458.24;8583.40;8651.57;8717.39;8742.39;8896.42;8904.60;8927.96;8960.73;8961.82;7483.48;7747.77;7763.46;7766.34;7773.07;7784.00;7821.41;7827.18;7849.18;7855.49;7012.16;7141.57;7250.09;7253.13;7335.89;6977.97;7015.51;7042.40;7204.35;7237.20;7160.46;7293.23;7321.27;7321.82;7331.16;6268.69;6324.11;6325.78;6328.56;6342.40;6554.54;6625.30;6646.00;6650.30;6674.90
4;prototype.html;237.05;251.94;256.61;259.65;263.52;4488.53;4676.88;4745.24;4745.50;4748.81;4648.47;4660.21;4666.58;4671.88;4677.32;3602.84;3611.40;3613.69;3615.69;3619.15;3604.41;3619.44;3623.24;3627.66;3628.11;3526.59;3589.35;3615.93;3616.35;3622.80;3624.69;3626.84;3628.47;3631.22;3632.15;3184.76;3186.11;3187.16;3187.78;3189.35;4353.43;4466.46;4482.57;4616.72;4617.88;4012.18;4034.84;4047.07;4047.82;4055.29;4815.11;4815.21;4816.11;4817.08;4820.40;3300.31;3345.18;3369.55;3420.98;3447.97;5026.99;5033.82;5034.50;5034.95;5038.97;3516.72;3520.79;3520.95;3521.81;3523.47;3565.29;3574.23;3574.37;3575.82;3578.37;4045.19;4053.51;4056.76;4058.76;4059.00;4714.67;4868.66;4869.66;4873.54;4878.29;1278.20;1300.92;1301.13;1301.17;1302.47;868.94;871.16;878.50;883.40;884.85;3874.71;3878.44;3881.61;3882.67;3886.92;4959.83;4968.45;4969.50;4971.38;4972.30;3862.69;3870.15;3871.79;3873.83;3878.07;2690.15;2711.66;2714.42;2715.39;2715.89;4349.04;4349.63;4351.33;4353.59;4355.46;4950.95;5101.08;5107.69;5120.21;5120.39;4336.63;4360.76;4361.96;4362.28;4365.43;4928.75;4939.41;4939.56;4943.95;4966.78;4869.03;4886.24;4888.85;4889.14;4895.76;4362.39;4362.78;4363.96;4365.00;4365.08;3408.00;3470.03;3476.37;3546.65;3547.34;4905.73;4926.21;4926.70;4926.93;4929.43;4682.88;4694.91;4696.30;4697.06;4699.69;4688.86;4691.25;4691.46;4698.37;4699.41;4628.07;4631.31;4633.42;4634.00;4636.00;4699.44;4796.02;4808.83;4809.95;4813.52;4719.10;4720.41;4722.95;4723.03;4723.53
5;yui.html;569.72;602.22;627.02;647.49;692.84;9978.30;10117.54;10121.70;10129.75;10137.24;9278.68;9291.44;9349.00;9370.53;9375.86;475.79;481.92;606.51;607.42;618.73;617.68;618.89;623.30;626.58;631.85;501.81;649.76;653.22;655.69;656.71;510.62;645.56;657.42;657.88;658.39;475.53;476.77;476.80;476.92;476.96;9895.16;9976.15;9988.25;9989.85;9996.40;9483.15;9545.75;9676.37;9808.51;10360.22;8331.29;8397.87;8538.06;8714.69;8803.78;2748.93;2800.93;2802.59;2857.33;2864.46;33757.16;33804.83;33859.32;33931.00;33991.32;7818.65;7846.92;7892.09;8170.55;8217.75;13691.38;13692.86;13693.25;13698.73;13706.66;5378.70;5517.83;5615.86;5616.16;5624.00;2985.63;3002.97;3003.07;3037.73;3038.87;2459.10;2502.52;2504.91;2507.07;2507.26;396.62;405.78;411.43;412.03;412.56;543.45;550.75;568.50;578.59;592.25;6762.21;6901.72;6984.27;7064.22;7122.29;454.78;519.40;539.29;543.96;566.16;3235.39;3266.13;3453.26;3498.79;3518.54;39079.22;39722.80;41350.59;41422.38;41540.17;34435.14;34606.31;34623.31;34661.00;34672.48;29449.12;29530.11;30507.24;31938.52;31961.52;7449.33;7524.62;7629.73;7712.96;7796.42;22917.43;23319.00;23441.41;23582.88;23583.53;29780.40;30272.55;31761.00;31765.84;31839.36;6112.45;6218.35;6476.68;6603.54;6793.66;10385.79;10471.69;10518.53;10552.74;10644.95;9563.52;9571.33;9617.09;9946.35;9976.80;9406.11;9518.48;9806.46;10102.44;10173.19;9482.43;9550.28;9878.21;9902.90;9951.45;8343.17;8511.00;8606.00;8750.21;8869.29;8234.96;8462.70;8473.49;8499.58;8808.91
</pre>
|}

===== Possible regression causes =====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

==== Dromaeo DOM (Linux64 only) ====
* contact: :bz, :jmaher
* source: [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/dromaeo dom.manifest]]
* type: PageLoader
* data: see Dromaeo DOM
* reporting: speed in test runs per second (higher is better)

Each page in the manifest is part of the dromaeo dom benchmark. These are the specific areas that Dromaeo DOM covers:

===== DOM Attributes =====
Measures performance of getting and setting a DOM attribute, both via <code>getAttribute</code> and via a reflecting DOM property. Also throws in some expando getting/setting for good measure.

====== Possible regression causes ======
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

===== DOM Modification =====
Measures performance of various things that modify the DOM tree: creating element and text nodes and inserting them into the DOM.

====== Possible regression causes ======
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

===== DOM Query =====
Measures performance of various methods of looking for nodes in the DOM: <code>getElementById</code>, <code>getElementsByTagName</code>, and so forth.

====== Possible regression causes ======
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

===== DOM Traversal =====
Measures performance of various accessors (<code>childNodes</code>, <code>firstChild</code>, etc) that would be used when doing a walk over the DOM tree.

====== Possible regression causes ======
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

Please see Dromaeo CSS for examples of data.

=== a11y ===
* contact: :davidb, :tbsaunde, :jmaher
* source: [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/a11y a11y.manifest]]
* type: PageLoader
* measuring: ???
* data: we load 2 pages 25 times each, collect 2 sets of 25 data points
* summarization
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 24; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l627 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 2 subtest results.

* reporting: test time in ms (lower is better)

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
|a11yr
|[[#Row_Major_vs._Column_Major|Row Major]] testing with 25 cycles per page
|}

This test ensures basic a11y tables and permutations do not cause performance regressions.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;dhtml.html;1584;1637;1643;1665;1741;1529;1647;1645;1692;1647;1542;1750;1654;1649;1541;1656;1674;1645;1645;1740;1558;1652;1654;1656;1654
1;tablemutation.html;398;385;389;391;387;387;385;387;388;385;384;31746;386;387;384;387;389;387;387;387;388;391;386;387;388
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== tscrollx ===
* contact: :jrmuizel, :jmaher, :avih
* source: [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/scroll scroll.manifest]]
* type: PageLoader
* measuring: Scroll performance
* reporting: Average frame interval (1/FPS). Lower is better.
* data: we load 6 pages 25 times each, collecting 6 sets of 25 data points
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 24; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l623 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 6 subtest results.

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
|tscrollx
|[https://groups.google.com/d/topic/mozilla.dev.platform/RICw5SJhNMo/discussion Replacing tscroll,tsvg with tscrollx,tsvgx]
|}

This test scrolls several pages where each represent a different known "hard" case to scroll (* needinfo), and measures the average frames interval (1/FPS) on each. The ASAP test (tscrollx) iterates in unlimited frame-rate mode thus reflecting the maximum scroll throughput per page. To turn on ASAP mode, we set these preferences:
preferences = {'layout.frame_rate': 0, 'docshell.event_starvation_delay_hint': 1}

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;tiled.html;5.41;5.57;5.34;5.64;5.53;5.48;5.44;5.49;5.50;5.50;5.49;5.66;5.50;5.37;5.57;5.54;5.46;5.31;5.41;5.57;5.50;5.52;5.71;5.31;5.44
fixed.html;10.404609053497941;10.47;10.66;10.45;10.73;10.79;10.64;10.64;10.82;10.43;10.92;10.47;10.47;10.64;10.74;10.67;10.40;10.83;10.77;10.54;10.38;10.70;10.44;10.38;10.56
downscale.html;5.493209876543211;5.27;5.50;5.50;5.51;5.46;5.58;5.58;5.51;5.49;5.49;5.47;9.09;5.56;5.61;5.50;5.47;5.59;5.47;5.49;5.60;5.61;5.58;5.40;5.43
downscale.html;10.676522633744854;10.82;10.79;10.41;10.75;10.91;10.52;10.61;10.50;10.55;10.80;10.17;10.68;10.41;10.42;10.41;10.58;10.28;10.56;10.66;10.68;10.47;10.60;10.61;10.26
4;iframe.svg;13.82;14.87;14.78;14.35;14.73;14.50;14.15;14.46;14.80;14.48;15.10;14.93;14.77;14.52;14.08;15.01;14.58;14.52;15.23;14.35;14.72;14.28;14.30;14.27;14.96
5;reader.htm;10.72;10.62;10.23;10.48;10.42;10.64;10.40;10.40;10.14;10.60;10.51;10.36;10.57;10.41;10.52;10.75;10.19;10.72;10.44;9.75;10.49;10.07;10.54;10.46;10.44
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== tresize ===
* contact: :jimm, :jmaher, :avih
* source: [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/startup_test/tresize/addon/content/tresize-test.html tresize-test.html]]
* type: StartupTest
* measuring: Time to do XUL resize, in ms (lower is better).
* data: we run the tresize test page 20 times, resulting in 1 set of 20 data points.
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] '''5''' data points, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 15 data points; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l205 source: test.py]
** suite: same as subtest result

A purer form of paint measurement than tpaint. This test opens a single window positioned at 10,10 and sized to 300,300, then resizes the window outward |max| times measuring the amount of time it takes to repaint each resize. Dumps the resulting dataset and average to stdout or logfile.

In {{bug|1102479}} tresize was rewritten to work in e10s mode which involved a full rewrite of the test.

To run resize locally without talos, please [https://hg.mozilla.org/mozilla-central/raw-file/tip/testing/talos/talos/generate-tresize-xpi.html install the addon] to run the test locally.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
[23.2565333333333, 23.763383333333362, 22.58369999999999, 22.802766666666653, 22.304050000000025, 23.010383333333326, 22.865466666666677, 24.233716666666705, 24.110983333333365, 22.21390000000004, 23.910333333333316, 23.409816666666647, 19.873049999999992, 21.103966666666686, 20.389749999999978, 20.777349999999984, 20.326283333333365, 22.341616666666667, 20.29813333333336, 20.769600000000104]
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== xperf ===
* contact: :aklotz, :jmaher
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/xtalos xperf instrumentation]
* type: Pageloader (tp5n) / Startup
* measuring: IO counters from windows (currently, only startup IO is in scope)
* reporting: Summary of read/write counters for disk, network (lower is better)

Talos will turn orange for 'x' jobs on windows 7 if your changeset accesses files which are not predefined in the [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/xtalos/xperf_whitelist.json whitelist]] during startup; specifically, before the "[https://hg.mozilla.org/mozilla-central/file/0eebc33d8593/toolkit/components/startup/nsAppStartup.cpp#l631 sessionstore-windows-restored]" Firefox event. If your job turns orange, you will see a list of files in Treeherder (or in the log file) which have been accessed unexpectedly (similar to this):
* TEST-UNEXPECTED-FAIL : xperf: File '{profile}\secmod.db' was accessed and we were not expecting it. DiskReadCount: 6, DiskWriteCount: 0, DiskReadBytes: 16904, DiskWriteBytes: 0
* TEST-UNEXPECTED-FAIL : xperf: File '{profile}\cert8.db' was accessed and we were not expecting it. DiskReadCount: 4, DiskWriteCount: 0, DiskReadBytes: 33288, DiskWriteBytes: 0
* TEST-UNEXPECTED-FAIL : xperf: File 'c:\$logfile' was accessed and we were not expecting it. DiskReadCount: 0, DiskWriteCount: 2, DiskReadBytes: 0, DiskWriteBytes: 32768 TEST-UNEXPECTED-FAIL : xperf: File '{profile}\secmod.db' was accessed and we were not expecting it. DiskReadCount: 6, DiskWriteCount: 0, DiskReadBytes: 16904, DiskWriteBytes: 0
* TEST-UNEXPECTED-FAIL : xperf: File '{profile}\cert8.db' was accessed and we were not expecting it. DiskReadCount: 4, DiskWriteCount: 0, DiskReadBytes: 33288, DiskWriteBytes: 0
* TEST-UNEXPECTED-FAIL : xperf: File 'c:\$logfile' was accessed and we were not expecting it. DiskReadCount: 0, DiskWriteCount: 2, DiskReadBytes: 0, DiskWriteBytes: 32768

In the case that these files are expected to be accessed during startup by your changeset, then we can add them to the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Testing&component=Talos whitelist].

Xperf runs tp5 while collecting xperf metrics for disk IO and network IO. The providers we listen for are:
* [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/xperf.config#l10 'PROC_THREAD', 'LOADER', 'HARD_FAULTS', 'FILENAME', 'FILE_IO', 'FILE_IO_INIT']

The values we collect during stackwalk are:
* [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/xperf.config#l11 'FileRead', 'FileWrite', 'FileFlush']

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== kraken ===
* contact: :h4writer, :jmaher
* source: [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/kraken kraken.manifest]]
* type: [https://wiki.mozilla.org/Buildbot/Talos#Page_Load_Tests PageLoader]
* measuring: JavaScript performance
* reporting: Total time for all tests, in ms (lower is better)
* data: there are 14 subtests in kraken, each subtest is an internal benchmark and generates 10 data points, or 14 sets of 10 data points.
* summarization:
** subtest: For all of the 10 data points, we take the [https://wiki.mozilla.org/Buildbot/Talos/Data#mean mean] to report a single number.
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 14 subtest results.

This is the [[Kraken]] javascript benchmark taken verbatim and slightly modified to fit into our pageloader extension and talos harness.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;ai-astar;100;95;98;102;101;99;97;98;98;102
1;audio-beat-detection;147;147;191;173;145;139;186;143;183;140
2;audio-dft;161;156;158;157;160;158;160;160;159;158
3;audio-fft;82;83;83;154;83;83;82;83;160;82
4;audio-oscillator;96;96;141;95;95;95;129;96;95;134
5;imaging-gaussian-blur;116;115;116;115;115;115;115;115;117;116
6;imaging-darkroom;166;164;166;165;166;166;165;165;165;166
7;imaging-desaturate;87;87;87;87;88;87;88;87;87;87
8;json-parse-financial;75;77;77;76;77;76;77;76;77;77
9;json-stringify-tinderbox;79;79;80;79;78;79;79;78;79;79
10;stanford-crypto-aes;98;97;96;98;98;98;98;98;113;95
11;stanford-crypto-ccm;130;138;130;127;137;134;134;132;147;129
12;stanford-crypto-pbkdf2;176;187;183;183;176;174;181;187;175;173
13;stanford-crypto-sha256-iterative;86;85;83;84;86;85;85;86;83;83
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== V8, version 7===
* contact: :h4writer, :jmaher
* source: [[https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/v8_7 v8.manifest]]
* type: PageLoader
* measuring: ???
* reporting: weighted score (higher is better)
* data: there are 10 subtests in kraken, each subtest is an internal benchmark and generates a single replicate.
* summarization:
** subtest: For all of the 10 data points, we take filter with [https://wiki.mozilla.org/Buildbot/Talos/Data#v8_subtest v8_subtest] to apply the reference value for the subtest to generate a single number. [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l489 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#v8_metric v8 metric] is basically the geometric mean of the 10 subtests and multiples the output by 100.

this is the V8 (version 7) javascript benchmark taken verbatim and slightly modified to fit into our pageloader extension and talos harness.

The previous version of this test is V8 version 5 which was run on selective branches and operating systems.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;Richards;152.99877600979192
1;DeltaBlue;210.7481559536354
2;Encrypt;291.29041654529567
3;Decrypt;5358.288770053476
4;RayTrace;1833.3333333333333
5;Earley;678.42605156038
6;Boyer;10265.30612244898
7;RegExp;28333.333333333332
8;Splay;528.2620179609086
9;NavierStokes;5055.555555555556
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== TART/CART ===
* contact: :avih, :jmaher, :MattN
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/tart tart]
* type: PageLoader
* measuring: Desktop Firefox UI animation speed and smoothness
* reporting: intervals in ms (lower is better) - see below for details
* data: there are 30 reported subtests from TART which we load 25 times, resulting in 30 sets of 25 data points.
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 24 data points; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l305 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 30 subtest results.

TART is the '''Tab Animation Regression Test''' and CART is the '''Customize Animation Regression Test'''.

TART tests tab animation on these cases:
* Simple: single new tab of about:blank open/close without affecting (shrinking/expanding) other tabs.
* icon: same as above with favicons and long title instead of about:blank.
* Newtab: newtab open with thumbnails preview - without affecting other tabs, with and without preload.
* Fade: opens a tab, then measures fadeout/fadein (tab animation without the overhead of opening/closing a tab).
** Case 1 is tested with DPI scaling of 1.
** Case 2 is tested with DPI scaling of 1.0 and 2.0.
** Case 3 is tested with the default scaling of the test system.
** Case 4 is tested with DPI scaling of 2.0 with the "icon" tab (favicon and long title).
** Each animation produces 3 test results:
*** error: difference between the designated duration and the actual completion duration from the trigger.
*** half: average frame interval over the 2nd half of the animation.
*** all: average frame interval over all recorded intervals.
*** And the run logs also include the explicit intervals from which these 3 values were derived.

CART uses the same framework to measure performance of the Australize "customize" animation (for entering the toolbar/menu customization view). Subtests include:
* Customize-enter animation (full and css-animation-only part).
* Customize-exit animation

TART/CART can be used as a stand-alone addon:
* Set the browser to ASAP mode (preferences layout.frame_rate=0, docshell.event_starvation_delay_hint=1). This makes the browser refresh the screen as fast as possible instead of limiting it to 60hz, thus allows higher resolution measurements. Requires restart to take effect.
* [https://hg.mozilla.org/mozilla-central/raw-file/tip/testing/talos/talos/generate-tart-xpi.html Install the latest addon xpi], or zip the addon dir of the source code, rename the extension to xpi and install.
* Visit chrome://tart/content/tart.html
* Select subtests to run. By default the selected tests are all the TART tests. CART is the "Customize" test.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;simple-open-DPI1.half.TART;2.35;2.42;2.63;2.47;2.71;2.38;2.37;2.41;2.48;2.70;2.44;2.41;2.51;2.43;2.41;2.56;2.76;2.49;2.36;2.40;2.70;2.53;2.35;2.46;2.47
1;simple-open-DPI1.all.TART;2.80;2.95;3.12;2.92;3.46;2.87;2.92;2.99;2.89;3.24;2.94;2.95;3.25;2.92;3.02;3.00;3.21;3.31;2.84;2.87;3.10;3.13;3.10;2.94;2.95
2;simple-open-DPI1.error.TART;33.60;36.33;35.93;35.97;38.17;34.77;36.00;35.01;36.25;36.22;35.24;35.76;36.64;36.31;34.74;34.40;34.34;41.48;35.04;34.83;34.27;34.04;34.37;35.22;36.52
3;simple-close-DPI1.half.TART;1.95;1.88;1.91;1.94;2.00;1.97;1.88;1.76;1.84;2.18;1.99;1.83;2.04;1.93;1.81;1.77;1.79;1.90;1.82;1.84;1.78;1.75;1.76;1.89;1.81
4;simple-close-DPI1.all.TART;2.19;2.08;2.07;2.32;2.65;2.32;2.26;1.96;2.02;2.26;2.05;2.16;2.19;2.11;2.04;1.98;2.05;2.02;2.01;2.11;1.97;1.97;2.05;2.01;2.12
5;simple-close-DPI1.error.TART;21.35;23.87;22.60;22.02;22.97;22.35;22.15;22.79;21.81;21.90;22.26;22.58;23.15;22.43;22.76;23.36;21.86;22.70;22.96;22.70;22.28;22.03;21.78;22.33;22.23
6;icon-open-DPI1.half.TART;2.42;2.33;2.50;2.58;2.36;2.51;2.60;2.35;2.52;2.51;2.59;2.34;3.29;2.63;2.46;2.57;2.53;2.50;2.39;2.51;2.44;2.66;2.72;2.36;2.52
7;icon-open-DPI1.all.TART;3.12;2.94;3.42;3.23;3.10;3.21;3.33;3.14;3.24;3.32;3.46;2.90;3.65;3.19;3.27;3.47;3.32;3.13;2.95;3.23;3.21;3.33;3.47;3.15;3.32
8;icon-open-DPI1.error.TART;38.39;37.96;37.03;38.85;37.03;37.17;37.19;37.56;36.67;36.33;36.89;36.85;37.54;38.46;35.38;37.52;36.68;36.48;36.03;35.71;37.12;37.08;37.74;38.09;35.85
9;icon-close-DPI1.half.TART;1.94;1.93;1.79;1.89;1.83;1.83;1.90;1.89;1.75;1.76;1.77;1.74;1.81;1.86;1.95;1.99;1.73;1.83;1.97;1.80;1.94;1.84;2.01;1.88;2.03
10;icon-close-DPI1.all.TART;2.14;2.14;1.98;2.03;2.02;2.25;2.29;2.13;1.97;2.01;1.94;2.01;1.99;2.05;2.11;2.09;2.02;2.02;2.12;2.02;2.20;2.11;2.19;2.07;2.27
11;icon-close-DPI1.error.TART;24.51;25.03;25.17;24.54;23.86;23.70;24.02;23.61;24.10;24.53;23.92;23.75;23.73;23.78;23.42;25.40;24.21;24.55;23.96;24.96;24.41;24.96;24.16;24.20;23.65
12;icon-open-DPI2.half.TART;2.60;2.60;2.60;2.53;2.51;2.53;2.59;2.43;2.66;2.60;2.47;2.61;2.64;2.43;2.49;2.63;2.61;2.60;2.52;3.06;2.65;2.74;2.69;2.44;2.43
13;icon-open-DPI2.all.TART;3.45;3.22;3.38;3.47;3.10;3.31;3.47;3.13;3.37;3.14;3.28;3.20;3.40;3.15;3.14;3.23;3.41;3.16;3.26;3.55;3.29;3.49;3.44;3.11;3.22
14;icon-open-DPI2.error.TART;40.20;37.86;37.53;41.46;37.03;38.77;37.48;36.97;37.28;37.72;36.09;36.71;38.89;38.21;37.37;38.91;36.79;36.10;37.60;36.99;37.56;35.76;38.92;37.46;37.52
15;icon-close-DPI2.half.TART;2.27;1.97;1.83;1.86;2.08;1.88;1.80;1.90;1.77;1.89;2.06;1.89;1.89;1.86;2.01;1.79;1.78;1.83;1.89;1.85;1.74;1.82;1.84;1.81;1.79
16;icon-close-DPI2.all.TART;2.33;2.13;2.18;2.03;2.33;2.03;1.95;2.06;1.96;2.13;2.25;2.10;2.13;2.03;2.18;2.00;2.05;2.01;2.08;2.05;1.96;2.04;2.10;2.04;2.08
17;icon-close-DPI2.error.TART;22.99;23.02;24.32;23.58;23.05;23.34;22.92;23.22;22.90;23.33;23.33;23.05;22.80;23.45;24.05;22.39;22.14;22.97;22.85;22.13;22.89;22.98;23.69;22.99;23.08
18;iconFade-close-DPI2.half.TART;2.14;1.84;1.78;1.84;1.66;2.07;1.81;3.82;1.68;1.85;1.62;2.54;2.06;1.85;2.17;1.80;1.71;1.67;2.11;1.73;2.94;2.14;1.93;1.72;2.05
19;iconFade-close-DPI2.all.TART;2.17;1.76;1.80;1.89;1.70;1.93;1.80;3.38;1.78;1.90;1.70;2.50;1.94;1.81;2.29;1.82;1.79;1.76;2.23;1.80;2.85;2.06;1.84;1.83;2.09
20;iconFade-close-DPI2.error.TART;4.67;4.11;3.69;4.51;4.46;3.88;4.54;3.68;4.56;3.82;4.32;4.87;4.42;3.72;3.72;4.54;4.93;4.46;4.64;3.39;4.09;3.28;3.58;4.11;3.80
21;iconFade-open-DPI2.half.TART;2.37;2.61;2.37;2.62;2.54;2.84;2.57;2.44;4.33;2.57;2.59;2.67;2.58;2.48;2.38;2.39;2.50;2.39;2.50;2.57;2.52;2.55;2.47;2.69;2.41
22;iconFade-open-DPI2.all.TART;2.45;2.64;2.39;2.60;2.57;2.60;2.61;2.59;3.14;2.55;2.54;2.66;2.57;2.48;2.47;2.46;2.55;2.45;2.51;2.61;2.54;2.58;2.50;2.54;2.40
23;iconFade-open-DPI2.error.TART;3.64;4.67;4.31;5.79;6.43;3.64;4.82;8.68;5.78;4.38;3.80;3.98;4.64;653.63;4.63;3.76;4.23;5.01;5.48;4.99;3.48;5.10;5.02;6.14;5.58
24;newtab-open-preload-no.half.TART;5.02;2.90;3.06;3.03;2.94;2.94;3.08;3.12;3.60;3.19;2.82;2.96;3.67;7.85;2.79;3.12;3.18;2.92;2.86;2.96;2.96;3.00;2.90;2.97;2.94
25;newtab-open-preload-no.all.TART;7.11;4.66;5.03;4.68;4.50;4.58;4.76;4.76;5.67;4.96;4.36;4.51;5.21;11.16;4.38;4.69;4.77;4.45;4.45;4.70;4.51;4.61;4.54;4.69;4.60
26;newtab-open-preload-no.error.TART;40.82;40.85;37.38;37.40;36.30;36.47;36.89;37.63;37.12;38.65;36.73;36.95;36.11;38.59;37.39;37.77;37.93;37.54;37.46;38.29;36.58;38.25;38.32;37.92;36.93
27;newtab-open-preload-yes.half.TART;3.14;2.96;2.97;8.37;2.98;3.00;2.96;3.05;3.12;3.48;3.07;3.23;3.05;2.88;2.92;3.06;2.90;3.01;3.19;2.90;3.18;3.11;3.04;3.16;3.21
28;newtab-open-preload-yes.all.TART;5.10;4.60;4.63;8.94;5.01;4.69;4.63;4.67;4.93;5.43;4.78;5.12;4.77;4.65;4.50;4.78;4.75;4.63;4.76;4.45;4.86;4.88;4.69;4.86;4.92
29;newtab-open-preload-yes.error.TART;35.90;37.24;38.57;40.60;36.04;38.12;38.78;36.73;36.91;36.69;38.12;36.69;37.79;35.80;36.11;38.01;36.59;38.85;37.14;37.30;38.02;38.95;37.64;37.86;36.43
</pre>
|}

==== Possible regression causes ====
* CART
** Regressions might be reported for patches that add new buttons to the menu panel by default, since this can add new rows to the panel and make it scrollable, which increases the amount of work to do during the transition. See {{bug|1230671}} for details.

=== DAMP ===

* contact: :bgrins, :jmaher
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/devtools damp]
* type: PageLoader
* measuring: Developer Tools toolbox startup, shutdown, and reload performance
* reporting: intervals in ms (lower is better) - see below for details
* data: there are 36 reported subtests from DAMP which we load 25 times, resulting in 36 sets of 25 data points.
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 24 data points; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l356 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 36 subtest results.

To run this locally, you'll need to pull down the tp5 page set and run it in a local web server. See the [https://wiki.mozilla.org/Buildbot/Talos/Tests#tp5 tp5 section] or contact jmaher for more information.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;simple.webconsole.open.DAMP;1198.86;354.38;314.44;337.32;344.73;339.05;345.55;358.37;314.89;353.73;324.02;339.45;304.63;335.50;316.69;341.05;353.45;353.73;342.28;344.63;357.62;375.18;326.08;363.10;357.30
1;simple.webconsole.reload.DAMP;44.60;41.21;25.62;29.85;38.10;42.29;38.25;40.14;26.95;39.24;40.32;34.67;34.64;44.88;32.51;42.09;28.04;43.05;40.62;36.56;42.44;44.11;38.69;29.10;42.00
2;simple.webconsole.close.DAMP;27.26;26.97;25.45;27.82;25.98;26.05;38.00;26.89;24.90;26.61;24.90;27.22;26.95;25.18;24.24;25.60;28.91;26.90;25.57;26.04;26.79;27.33;25.76;26.47;27.43
3;simple.inspector.open.DAMP;507.80;442.03;424.93;444.62;412.94;451.18;441.39;435.83;441.27;460.69;440.93;413.13;418.73;443.41;413.93;447.34;434.69;459.24;453.60;412.58;445.41;466.34;441.89;417.59;428.82
4;simple.inspector.reload.DAMP;169.45;165.11;163.93;181.12;167.86;164.67;170.34;173.12;165.24;180.59;176.72;187.42;170.14;190.35;176.59;155.00;151.66;174.40;169.46;163.85;190.93;217.00;186.25;181.31;161.13
5;simple.inspector.close.DAMP;44.40;42.28;42.71;47.21;41.74;41.24;42.94;43.73;48.24;43.04;48.61;42.49;45.93;41.36;43.83;42.43;41.81;43.93;41.38;40.98;49.76;50.86;43.49;48.99;44.02
6;simple.jsdebugger.open.DAMP;642.59;464.02;540.62;445.46;471.09;466.57;466.70;511.91;424.12;480.70;448.37;477.51;488.99;437.97;442.32;459.03;421.54;467.99;472.78;440.27;431.47;454.76;436.86;453.61;485.59
7;simple.jsdebugger.reload.DAMP;51.65;55.46;225.46;53.32;58.78;53.23;54.39;51.59;55.46;48.03;50.70;46.34;230.94;53.71;54.23;53.01;61.03;51.23;51.45;293.01;56.93;51.44;59.85;63.35;57.44
8;simple.jsdebugger.close.DAMP;29.12;30.76;40.34;32.09;31.26;32.30;33.95;31.89;29.68;31.39;32.09;30.36;44.63;32.33;30.16;32.43;30.89;30.85;31.99;49.86;30.94;44.63;32.54;29.79;33.15
9;simple.styleeditor.open.DAMP;758.54;896.93;821.17;1026.24;887.14;867.39;927.86;962.80;740.40;919.39;741.01;925.21;807.39;1051.47;729.04;1095.78;755.03;888.70;900.52;810.30;1090.09;869.72;737.44;893.16;927.72
10;simple.styleeditor.reload.DAMP;57.32;178.13;59.23;60.82;71.45;78.86;74.35;60.11;66.43;77.41;61.96;69.22;65.97;45.53;67.88;74.76;124.61;60.01;36.66;59.24;65.01;165.68;34.61;69.02;71.42
11;simple.styleeditor.close.DAMP;28.28;56.50;36.18;30.00;36.32;34.85;35.33;36.24;25.45;36.72;26.53;36.90;28.88;30.94;26.56;31.34;47.79;30.90;30.52;27.95;30.75;56.28;26.76;30.25;37.42
12;simple.performance.open.DAMP;444.28;357.87;331.17;335.16;585.71;402.99;504.58;466.95;272.98;427.54;345.60;441.53;319.99;327.91;312.94;349.79;399.51;465.60;418.42;295.14;362.06;363.11;445.71;634.96;500.83
13;simple.performance.reload.DAMP;38.07;33.44;35.99;70.57;64.04;106.47;148.31;29.60;68.47;28.95;148.46;75.92;32.15;93.72;36.17;44.13;75.11;154.76;98.28;75.16;29.39;36.68;113.16;64.05;135.60
14;simple.performance.close.DAMP;23.98;25.49;24.19;24.61;27.56;40.33;33.85;25.13;22.62;25.28;41.84;25.09;26.39;25.20;23.76;25.44;25.92;30.40;40.77;25.41;24.57;26.15;43.65;28.54;30.16
15;simple.netmonitor.open.DAMP;438.85;350.64;318.04;329.12;341.91;352.33;344.05;334.15;514.57;327.95;471.50;334.55;344.94;364.39;727.56;374.48;339.45;344.31;345.61;329.78;325.74;334.74;350.36;342.85;344.64
16;simple.netmonitor.reload.DAMP;59.68;47.50;69.37;61.18;76.89;83.22;68.11;81.24;56.15;68.20;32.41;81.22;81.62;44.30;39.52;29.60;86.07;71.18;76.32;79.93;79.63;82.15;83.58;87.04;82.97
17;simple.netmonitor.close.DAMP;38.42;39.32;52.56;43.37;48.08;40.62;51.12;41.11;59.54;43.29;41.72;40.85;51.61;49.61;51.39;44.91;40.36;41.10;45.43;42.15;42.63;40.69;41.21;44.04;41.95
18;complicated.webconsole.open.DAMP;589.97;505.93;480.71;530.93;460.60;479.63;485.33;489.08;605.28;457.12;463.95;493.28;680.05;478.72;504.47;578.69;488.66;485.34;504.94;460.67;548.38;474.98;470.33;471.34;464.58
19;complicated.webconsole.reload.DAMP;2707.20;2700.17;2596.02;2728.09;2905.51;2716.65;2657.68;2707.74;2567.86;2726.36;2650.92;2839.14;2620.34;2718.36;2595.22;2686.28;2703.48;2609.75;2686.41;2577.93;2634.47;2745.56;2655.89;2540.09;2649.18
20;complicated.webconsole.close.DAMP;623.56;570.80;636.63;502.49;565.83;537.93;525.46;565.78;532.90;562.66;525.42;490.88;611.99;486.45;528.60;505.35;480.55;500.75;532.75;480.91;488.69;548.77;535.31;477.92;519.84
21;complicated.inspector.open.DAMP;1233.26;753.57;742.74;953.11;653.29;692.66;653.75;767.02;840.68;707.56;713.95;685.79;690.21;1020.47;685.67;721.69;1063.72;695.55;702.15;760.91;853.14;660.12;729.16;1044.86;724.34
22;complicated.inspector.reload.DAMP;2384.90;2436.35;2356.11;2436.58;2372.96;2558.86;2543.76;2351.03;2411.95;2358.04;2413.27;2339.85;2373.11;2338.94;2418.88;2360.87;2349.09;2498.96;2577.73;2445.07;2354.88;2424.90;2696.10;2362.39;2493.29
23;complicated.inspector.close.DAMP;541.96;509.38;476.91;456.48;545.48;634.04;603.10;488.09;599.20;480.45;617.93;420.39;514.92;439.99;727.41;469.04;458.59;539.74;611.55;725.03;473.36;484.60;481.46;458.93;554.76
24;complicated.jsdebugger.open.DAMP;644.97;578.41;542.23;595.94;704.80;603.08;689.18;552.99;597.23;584.17;682.14;758.16;791.71;738.43;640.30;809.26;704.85;601.32;696.10;683.44;796.34;657.25;631.89;739.96;641.82
25;complicated.jsdebugger.reload.DAMP;2676.82;2650.84;2687.78;2401.23;3421.32;2450.91;2464.13;2286.40;2399.40;2415.97;2481.48;2827.69;2652.03;2554.63;2631.36;2443.83;2564.73;2466.22;2597.57;2552.73;2539.42;2481.21;2319.50;2539.00;2576.43
26;complicated.jsdebugger.close.DAMP;795.68;616.48;598.88;536.77;435.02;635.61;558.67;841.64;613.48;886.60;581.38;580.96;571.40;605.34;671.00;882.02;619.01;579.63;643.05;656.78;699.64;928.99;549.76;560.96;676.32
27;complicated.styleeditor.open.DAMP;2327.30;2494.19;2190.29;2205.60;2198.11;2509.01;2189.79;2532.05;2178.03;2207.75;2224.96;2665.84;2294.40;2645.44;2661.41;2364.60;2395.36;2582.72;2872.03;2679.29;2561.24;2330.11;2580.16;2510.36;2860.83
28;complicated.styleeditor.reload.DAMP;2218.46;2335.18;2284.20;2345.05;2286.98;2453.47;2506.97;2661.19;2529.51;2289.78;2564.15;2608.24;2270.77;2362.17;2287.31;2300.19;2331.56;2300.86;2239.27;2231.33;2476.14;2286.28;2583.24;2540.29;2259.67
29;complicated.styleeditor.close.DAMP;302.67;343.10;313.15;305.60;317.92;328.44;350.70;370.12;339.77;308.72;312.71;320.63;305.52;316.69;324.92;306.60;313.65;312.17;326.26;321.45;334.56;307.38;312.95;350.94;339.36
30;complicated.performance.open.DAMP;477.99;537.96;564.85;515.05;502.03;515.58;492.80;689.06;448.76;588.91;509.76;485.39;548.17;479.14;638.67;535.86;541.61;611.52;554.72;665.37;694.04;470.60;746.16;547.85;700.02
31;complicated.performance.reload.DAMP;2258.31;2345.74;2509.24;2579.71;2367.94;2365.94;2260.86;2324.23;2579.01;2412.63;2540.38;2069.80;2534.91;2443.48;2193.01;2442.99;2422.42;2475.35;2076.48;2092.95;2444.53;2353.86;2154.28;2354.61;2104.82
32;complicated.performance.close.DAMP;334.44;516.66;432.49;341.29;309.30;365.20;332.16;311.42;370.81;301.81;381.13;299.39;317.60;314.10;372.44;314.76;306.24;349.85;382.08;352.53;309.40;298.44;314.10;315.44;405.22
33;complicated.netmonitor.open.DAMP;469.70;597.87;468.36;823.09;696.39;477.19;487.78;495.92;587.89;471.48;555.02;507.45;883.33;522.15;756.86;713.64;593.82;715.13;477.15;717.85;586.79;556.97;631.43;629.55;581.16
34;complicated.netmonitor.reload.DAMP;4033.55;3577.36;3655.61;3721.24;3874.29;3977.92;3778.62;3825.60;3984.65;3707.91;3985.24;3565.21;3702.40;3956.70;3627.14;3916.11;3929.11;3934.06;3590.60;3628.39;3618.84;3579.52;3953.04;3781.01;3682.69
35;complicated.netmonitor.close.DAMP;1042.98;920.21;928.19;940.38;950.25;1043.61;1078.16;1077.38;1132.91;1095.05;1176.31;1256.83;1143.14;1234.61;1248.97;1242.29;1378.63;1312.74;1371.48;1373.15;1544.55;1422.51;1549.48;1616.55;1506.58
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== sessionrestore/sessionrestore_no_auto_restore/sessionrestore_many_windows ===
* contact: :Yoric, :mikedeboer
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/startup_test/sessionrestore talos/sessionrestore]
* bug: https://bugzilla.mozilla.org/show_bug.cgi?id=936630, https://bugzilla.mozilla.org/show_bug.cgi?id=1331937
* type: Startup
* measuring: time spent reading and restoring the session.
* reporting: interval in ms (lower is better).
* data: we load the session restore index page 10 times to collect 1 set of 10 data points.
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 9 data points; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l305 source: test.py]
** suite: identical to subtest

Three tests measure the time spent reading and restoring the session from a valid sessionstore.js. Time starts ticking during event sessionRestoreInit and stops during event sessionRestored.

In ''sessionrestore'', this is tested with a configuration that requires the session to be restored. In ''sessionrestore_no_auto_restore'', this is tested with a configuration that requires the session to not be restored. Both of the above tests use a sessionstore.js file that contains one window and roughly 89 tabs. In ''sessionrestore_many_windows'', this is tested with a sessionstore.js that contains 3 windows and 130 tabs. The first window contains 50 tabs, 80 remaning tabs are divided equally between the second and the third window.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
[2362.0, 2147.0, 2171.0, 2134.0, 2116.0, 2145.0, 2141.0, 2141.0, 2136.0, 2080.0]
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== tps ===
* contact: :blassey, :mconley
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/tabswitch tabswitch]
* bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1166132
* type: Pageloader
* measuring:
** The time between switching a tab and the first paint to the content area
* reporting:
* data: we load 50 web pages 5 times each, resulting in 50 sets of 5 data points.
* '''To run it locally''', you'd need [[#tp5n_pages_set|tp5n.zip]].
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 4 data points; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l305 source: test.py]
** suite: [https://wiki.mozilla.org/Buildbot/Talos/Data#geometric_mean geometric mean] of the 50 subtest results.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;amazon.com/www.amazon.com/Kindle-Wireless-Reader-Wifi-Graphite/dp/B002Y27P3M/507846.html;66.34;54.15;53.08;55.79;49.12
1;cgi.ebay.com/cgi.ebay.com/ALL-NEW-KINDLE-3-eBOOK-WIRELESS-READING-DEVICE-W-WIFI-/130496077314@pt=LH_DefaultDomain_0&hash=item1e622c1e02.html;50.85;46.57;39.51;36.71;36.47
2;163.com/www.163.com/index.html;95.05;80.80;76.09;69.29;68.96
3;mail.ru/mail.ru/index.html;66.21;52.04;56.33;55.11;45.61
4;bbc.co.uk/www.bbc.co.uk/news/index.html;35.80;44.59;48.02;45.71;42.58
5;store.apple.com/store.apple.com/us@mco=Nzc1MjMwNA.html;52.98;49.45;58.47;56.79;61.29
6;imdb.com/www.imdb.com/title/tt1099212/index.html;46.51;55.12;46.22;50.60;47.63
7;cnn.com/www.cnn.com/index.html;43.02;50.77;43.88;49.70;50.02
8;sohu.com/www.sohu.com/index.html;74.03;62.89;63.30;67.71;89.35
9;youku.com/www.youku.com/index.html;43.98;52.69;45.80;63.00;57.02
10;ifeng.com/ifeng.com/index.html;88.01;87.54;104.47;94.93;113.91
11;tudou.com/www.tudou.com/index.html;45.32;48.10;46.03;39.26;58.38
12;chemistry.about.com/chemistry.about.com/index.html;38.24;37.07;39.59;39.48;39.60
13;beatonna.livejournal.com/beatonna.livejournal.com/index.html;35.59;50.75;36.17;48.49;52.61
14;rakuten.co.jp/www.rakuten.co.jp/index.html;90.28;71.95;62.66;60.33;67.76
15;uol.com.br/www.uol.com.br/index.html;42.89;48.05;53.77;40.02;42.41
16;thepiratebay.org/thepiratebay.org/top/201.html;40.46;42.46;47.63;57.66;45.49
17;page.renren.com/page.renren.com/index.html;47.61;66.78;47.91;62.78;47.19
18;chinaz.com/chinaz.com/index.html;50.34;58.17;118.43;55.47;63.80
19;globo.com/www.globo.com/index.html;41.34;38.52;42.82;53.14;45.20
20;spiegel.de/www.spiegel.de/index.html;33.60;34.34;36.25;36.18;47.04
21;dailymotion.com/www.dailymotion.com/us.html;37.68;36.13;39.52;37.15;42.79
22;goo.ne.jp/goo.ne.jp/index.html;50.74;47.30;63.04;58.41;58.96
23;stackoverflow.com/stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered.html;44.66;44.40;43.39;47.38;57.65
24;ezinearticles.com/ezinearticles.com/index.html@Migraine-Ocular---The-Eye-Migraines&id=4684133.html;37.38;45.01;40.29;36.26;39.28
25;huffingtonpost.com/www.huffingtonpost.com/index.html;39.57;43.35;55.01;44.13;58.28
26;media.photobucket.com/media.photobucket.com/image/funny%20gif/findstuff22/Best%20Images/Funny/funny-gif1.jpg@o=1.html;39.77;42.46;75.54;42.38;47.72
27;imgur.com/imgur.com/gallery/index.html;34.72;37.37;46.74;40.93;37.08
28;reddit.com/www.reddit.com/index.html;42.47;39.89;51.54;51.51;41.68
29;noimpactman.typepad.com/noimpactman.typepad.com/index.html;54.28;47.40;52.38;52.15;50.97
30;myspace.com/www.myspace.com/albumart.html;48.97;64.12;61.66;48.32;68.53
31;mashable.com/mashable.com/index.html;36.76;40.95;35.30;53.86;42.76
32;dailymail.co.uk/www.dailymail.co.uk/ushome/index.html;42.06;40.64;44.24;37.32;61.35
33;whois.domaintools.com/whois.domaintools.com/mozilla.com.html;34.73;35.23;39.25;48.24;35.72
34;indiatimes.com/www.indiatimes.com/index.html;52.67;55.51;46.29;52.69;58.82
35;reuters.com/www.reuters.com/index.html;32.92;33.08;36.95;39.23;39.27
36;xinhuanet.com/xinhuanet.com/index.html;125.85;102.56;138.89;130.34;147.45
37;56.com/www.56.com/index.html;63.89;75.00;61.45;62.20;58.67
38;bild.de/www.bild.de/index.html;35.61;43.74;34.79;33.45;31.83
39;guardian.co.uk/www.guardian.co.uk/index.html;38.91;55.93;62.34;42.63;45.99
40;naver.com/www.naver.com/index.html;78.10;89.07;127.67;75.18;109.32
41;yelp.com/www.yelp.com/biz/alexanders-steakhouse-cupertino.html;42.54;46.92;39.19;49.82;50.43
42;wsj.com/online.wsj.com/home-page.html;46.43;55.51;44.16;81.79;48.78
43;google.com/www.google.com/search@q=mozilla.html;35.62;36.71;44.47;45.00;40.22
44;xunlei.com/xunlei.com/index.html;67.57;60.69;83.83;85.53;85.08
45;aljazeera.net/aljazeera.net/portal.html;65.03;51.84;73.29;64.77;69.70
46;w3.org/www.w3.org/standards/webdesign/htmlcss.html;53.57;58.50;72.98;66.95;55.62
47;homeway.com.cn/www.hexun.com/index.html;105.59;117.32;108.95;116.10;70.32
48;youtube.com/www.youtube.com/music.html;40.53;41.48;59.67;40.81;40.07
49;people.com.cn/people.com.cn/index.html;96.49;103.64;115.12;66.05;117.84
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== Microbench ===
* contact: :benwa
* source: [[https://dxr.mozilla.org/mozilla-central/source/testing/gtest/mozilla/MozGTestBench.cpp MozGTestBench.cpp]]
* type: Custom GTest micro-benchmarking
* data: Time taken for a GTest function to execute
* summarization: Not a Talos test. This suite is provides a way to add low level platform performance regression tests for things that are not suited to be tested by Talos. See the [[https://wiki.mozilla.org/Buildbot/Talos/Sheriffing#Microbench_Policy Microbench Sheriffing Policy]] for some notes on how to treat regressions.

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== tabpaint ===
* contact: :mconley
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/tabpaint tabpaint]
* bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1253382
* type: Pageloader
* measuring:
** The time it takes to paint the content of a newly opened tab when the tab is opened from the parent (ex: by hitting Ctrl-T)
** The time it takes to paint the content of a newly opened tab when the tab is opened from content (ex: by clicking on a target="_blank" link)
* '''NOT''' measuring:
** The time it takes to animate the tabs. That's the responsibility of the TART test. tabpaint is strictly concerned with the painting of the web content.
* data: we load the tabpaint trigger page 20 times, each run produces two values (the time it takes to paint content when opened from the parent, and the time it takes to paint content when opened from content), resulting in 2 sets of 20 data points.
** Example:
{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
0;tabpaint-from-parent;105;76;66;64;64;69;65;63;70;68;64;60;65;63;54;61;64;67;61;64
1; tabpaint-from-content;129;68;72;72;70;78;86;85;82;79;120;92;76;80;74;82;76;89;77;85
</pre>
|}

* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] data point, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 19 data points
** suite: geometric_mean(subtests)

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== Other data ===

These are not part of the Talos code, but like Talos they are benchmarks that record data using the graphserver and are analyzed by the same scripts for regressions.

==== Number of Constructors (num_ctors) ====

This test runs at build time and measures the number of static initializers in the compiled code. Reducing this number is helpful for [https://blog.mozilla.org/tglek/2010/05/27/startup-backward-constructors/ startup optimizations].

* https://hg.mozilla.org/build/tools/file/348853aee492/buildfarm/utils/count_ctors.py
** these are run for linux 32+64 opt and pgo builds.

===== Possible regression causes =====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== bloom_basic ===
* contact: :bholley, :rwood, :jmaher
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/perf-reftest perf-reftest]
* type: [https://wiki.mozilla.org/Buildbot/Talos/Tests#Page_Load_Tests PageLoader]
* reporting: intervals in ms (lower is better)
* data: each test loads 25 times
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] 5 data points, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 20 data points; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l734 source: test.py]
** suite: identical to subtest

The bloom_basic test (perf-reftest suite) is a unique talos suite that loads two different test pages: a 'base' page (bloom_basic) and a 'reference' page (bloom_basic_ref), and then compares each of the page load times against eachother to determine the variance.

Talos runs each of the two pages as if they are stand-alone tests, and then calculates and reports the variance; the test output 'replicates' reported from bloom_basic are actually the comparisons between the 'base' and 'reference' pages for each page load cycle.

If you wish to see the individual 'base' and 'reference' page results instead of just the reported difference, the 'base_replicates' and 'ref_replicates' can be found in the PERFHERDER_DATA log file output, and in the 'local.json' talos output file when running talos locally. In production, both of the page replicates are also archived in the perfherder-data.json file. The perfherder-data.json file is archived after each run in production, and can be found on the Treeherder Job Details tab when the perf-reftest job symbol is selected.

Bloom_basic ensures that we correctly fast-reject ancestor selectors that clearly don't
match any ancestor elements. If the bloom filter isn't working correctly,
the 'test' page will take orders of magnitude longer. The 'ref' page will
take somewhat longer, but not nearly as much.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
"replicates": [1.185, 1.69, 1.22, 0.36, 11.26, 3.835, 3.315, 1.355, 3.185, 2.485, 2.2, 1.01, 0.9, 1.22, 1.9,
0.285, 1.52, 0.31, 2.58, 0.725, 2.31, 2.67, 3.295, 1.57, 0.3], "value": 1.7349999999999999, "unit": "ms",

"base_replicates": [166.94000000000003, 165.16, 165.64000000000001, 165.04000000000002, 167.355, 165.175,
165.325, 165.11, 164.175, 164.78, 165.555, 165.885, 166.83499999999998, 165.76500000000001, 164.375, 166.825,
167.13, 166.425, 169.22500000000002, 164.955, 165.335, 164.45000000000002, 164.85500000000002, 165.005, 166.035]}],

"ref_replicates": [165.755, 166.85000000000002, 166.85999999999999, 165.4, 178.615, 169.01, 168.64, 166.465,
167.36, 167.265, 167.75500000000002, 166.895, 167.735, 166.985, 166.275, 166.54000000000002, 165.61, 166.115,
166.64499999999998, 165.68, 167.64499999999998, 167.12, 168.15, 166.575, 166.335],
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== bloom_basic_singleton ===
* contact: :bholley, :rwood, :jmaher
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/perf-reftest-singletons perf-reftest-singletons]
* type: [https://wiki.mozilla.org/Buildbot/Talos/Tests#Page_Load_Tests PageLoader]
* reporting: intervals in ms (lower is better)
* data: each test loads 25 times
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first] 5 data points, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 20 data points; [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/test.py#l734 source: test.py]
** suite: identical to subtest

The bloom_basic_singleton test (perf-reftest-singletons suite) runs the 'base' page (bloom_basic) test individually, and reports the values for that single test page alone, NOT the comparison of two different pages.

Bloom_basic ensures that we correctly fast-reject ancestor selectors that clearly don't
match any ancestor elements. If the bloom filter isn't working correctly,
the 'test' page will take orders of magnitude longer. The 'ref' page will
take somewhat longer, but not nearly as much.

{| class="mw-collapsible mw-collapsed wikitable"
! Example data
|-
| <pre>
bloombasic.html;88.34000000000003;88.66499999999999;94.815;92.60500000000002;95.30000000000001;
98.80000000000001;91.975;87.73500000000001;86.925;86.965;93.00500000000001;98.93;87.45000000000002;
87.14500000000001;92.78500000000001;86.96499999999999;98.32000000000001;97.485;90.67000000000002;
86.72500000000001;95.665;100.67;101.095;94.32;91.87
</pre>
|}

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== tp6 ===
* contact: :rwood, :jmaher, :bsmedberg
* source: [https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/tests/quantum_pageload tp6]
* type: [https://wiki.mozilla.org/Buildbot/Talos/Tests#Page_Load_Tests PageLoader]
* reporting: intervals in ms (lower is better)
* data: we load each of the tp6 pages 25 times
* summarization:
** subtest: [https://wiki.mozilla.org/Buildbot/Talos/Data#ignore_first ignore first five] data points, then take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the remaining 20; [http://searchfox.org/mozilla-central/rev/8a61c71153a79cda2e1ae7d477564347c607cc5f/testing/talos/talos/test.py#246 source: test.py]
** suite: identical to subtest; each tp6_* test is reported individually (they're NOT aggregated)

* NOTE: Currently only supported on Windows

The talos tp6 (also known as 'quantum-pageload') test suite loads various pages and reports their load times. Each test page/URL is reported individually. The result values (ms) is the 'time to first non-blank paint'.

Instead of loading the page sets from a local file, a tool called [http://docs.mitmproxy.org/en/latest/introduction.html mitmproxy] is used to playback page archives via an https proxy. When the tp6 suite is run via ./mach talos-test, mozharness automatically downloads and installs the mitmproxy tool and pageset archives.

The mitmproxy tool is started, the proxy setup in Firefox, and the mitmproxy https security certificate is loaded into Firefox, all automatically. The pagesets are made available for playback via the proxy, at which point each of the tp6 test pages are ready for load and measurement.

The tp6 suite currently consists of these individual pageload tests:

{| cellspacing="1" cellpadding="1" border="1"
|-
| Talos test name
| Description
|-
| tp6_amazon
| Measures page load of an amazon search result for the keyword "laptop"
|-
| tp6_facebook
| Measures page load of a facebook timeline (post-login)
|-
| tp6_google
| Measures page load of a google search result for the keywords "barack obama"
|-
| tp6_youtube
| Measures page load of the youtube home page
|}

{| class="mw-collapsible mw-collapsed wikitable"
! Example data for tp6_youtube
|-
| <pre>
https://www.youtube.co/;409;441;354;337;326;375;353;650;354;712;667;336;791;497;342;355;611;334;
692;320;714;434;582;610;333
</pre>
|}

==== Possible regression causes ====
Some examples of things that cause regressions in this test are:
* Please update this when regressions are found

=== Stylo gtest microbenchmarks ===

* contact: :bholley, :SimonSapin
* source: [https://dxr.mozilla.org/mozilla-central/source/layout/style/test/gtest]
* type: [https://wiki.mozilla.org/Buildbot/Talos/Tests#Microbench Microbench]
* reporting: intervals in ms (lower is better)
* data: each test is run and measured 5 times
* summarization: take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the 5 data points; [https://dxr.mozilla.org/mozilla-central/source/testing/gtest/mozilla/MozGTestBench.cpp#43-46 source: MozGTestBench.cpp]

Servo_StyleSheet_FromUTF8Bytes_Bench parses a sample stylesheet 20 times with Stylo’s CSS parser that is written in Rust. It starts from an in-memory UTF-8 string, so that I/O or UTF-16-to-UTF-8 conversion is not measured.

Gecko_nsCSSParser_ParseSheet_Bench does the same with Gecko’s previous CSS parser that is written in C++, for comparison.

Servo_DeclarationBlock_SetPropertyById_Bench parses the string "10px" with Stylo’s CSS parser and sets it as the value of a property in a declaration block, a million times. This is similar to animations that are based on JavaScript code modifying Element.style instead of using CSS @keyframes.

Servo_DeclarationBlock_SetPropertyById_WithInitialSpace_Bench is the same, but with the string " 10px" with an initial space. That initial space is less typical of JS animations, but is almost always there in stylesheets or full declarations like "width: 10px". This microbenchmark was used to test the effect of some specific code changes. Regressions here may be acceptable if Servo_StyleSheet_FromUTF8Bytes_Bench is not affected.

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== IsASCII and IsUTF8 gtest microbenchmarks ===

* contact: :hsivonen
* source: [https://dxr.mozilla.org/mozilla-central/source/xpcom/tests/gtest/TestStrings.cpp]
* type: [https://wiki.mozilla.org/Buildbot/Talos/Tests#Microbench Microbench]
* reporting: intervals in ms (lower is better)
* data: each test is run and measured 5 times
* summarization: take the [https://wiki.mozilla.org/Buildbot/Talos/Data#median median] of the 5 data points; [https://dxr.mozilla.org/mozilla-central/source/testing/gtest/mozilla/MozGTestBench.cpp#43-46 source: MozGTestBench.cpp]

Test whose name starts with PerfIsASCII test the performance of the XPCOM string IsASCII function with ASCII inputs if different lengths.

Test whose name starts with PerfIsUTF8 test the performance of the XPCOM string IsUTF8 function with ASCII inputs if different lengths.

==== Possible regression causes ====
* The --enable-rust-simd accidentally getting turned off in automation.
* Changes to encoding_rs internals.
* LLVM optimizations regressing between updates to the copy of LLVM included in the Rust compiler.

=== TestStandardURL ===

* contact: :valentin
* source:
* type:
* reporting:
* data:
* summarization:

TestStandardURL.Perf - Runs 10K iterations on the most important getters and setters of nsStandardURL

TestStandardURL.NormalizePerf - Runs 20K x 5 iterations on nsStandardURL::NormalizeIPv4 on input that are valid IPv4 strings

TestStandardURL.NormalizePerfFails - Runs 20K x 5 iterations on nsStandardURL::NormalizeIPv4 on input that is not valid IPv4

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

=== PerfStrip Tests ===

* contact: :milan
* source: https://dxr.mozilla.org/mozilla-central/source/xpcom/tests/gtest/TestStrings.cpp
* type: Microbench
* reporting: execution time in ms (lower is better) for 100k function calls
* data: each test run and measured 5 times
* summarization:

PerfStripWhitespace - call StripWhitespace() on 5 different test cases 20k times (each)

PerfStripCharsWhitespace - call StripChars("\f\t\r\n") on 5 different test cases 20k times (each)

PerfStripCRLF - call StripCRLF() on 5 different test cases 20k times (each)

PerfStripCharsCRLF() - call StripChars("\r\n") on 5 different test cases 20k times (each)

==== Possible regression causes ====
* None listed yet. If you fix a regression for this test and have some tips to share, this is a good place for them.

Oxidation

2017-07-07T17:39:36Z

Hsivonen: Apparently the switch over to mp4parse isn't complete yet

'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code into Gecko and Firefox.

* Tracking: {{bug|oxidation}}
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]
* [https://gecko.readthedocs.io/en/latest/build/buildsystem/rust.html Build System Documentation]

Which components will use Rust code?

* Completed
** Replace uconv with encoding-rs: {{bug|1261841}} (shipping in Firefox 56)
* In progress
** Replace stagefright's MP4 metadata parser with mp4parse crate {{bug|1161350}}
** URL parser: {{bug|url-oxidation}}
** CSS style calculation (from Servo): {{bug|stylo}}
** WebM demuxer: {{bug|1267492}}
** WebRender (from Servo): {{bug|webrender}}
** Audio remoting for Linux: {{bug|1362220}}
** SDP parsing in WebRTC {{bug|1365792}}
* Proposed
** Replace the XML parser
** Replace the preferences module
** Replace the telemetry module(?)
** Share media playback stack with Servo(?)
** Replace DOM serializers (XML, HTML for Save As.., plain text)

What is the high-level status of things?
* We are actively adding new code modules written in Rust to Firefox.
* Rust has been *required* on all platforms since Firefox 54.

== Raw Rust code (lives in m-c) blockers ==

* Top-level metabug {{bug|oxidation}}
* Android support {{bug|1220307}}
* Linux distro support for Rust [https://internals.rust-lang.org/t/perfecting-rust-packaging/2623]
* Need to improve call stacks {{bug|1268328 }}

== Cargo / GitHub blockers ==

* Tracking bug {{bug|1231764}}
* Improve working with vendored Cargo crates [https://github.com/rust-lang/cargo/issues/1926] [https://github.com/rust-lang/cargo/issues/2212]

== Rust / Cargo nice-to-haves ==

* Per-crate integer overflow checking [https://github.com/rust-lang/cargo/issues/2262]
* Artifact caching [https://github.com/rust-lang/cargo/issues/1997]

== Meetings ==

* Mozlando [https://github.com/servo/servo/wiki/Mozlando-Oxidation]
* Oxidation Nov. 2015 [https://github.com/servo/servo/wiki/Oxidation-2015-11-05]
* Mozlandia [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko]
* Whistler [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko]

Oxidation

2017-07-07T07:52:59Z

Hsivonen: Clarify what mp4parse replaced

'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code into Gecko and Firefox.

* Tracking: {{bug|oxidation}}
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]
* [https://gecko.readthedocs.io/en/latest/build/buildsystem/rust.html Build System Documentation]

Which components will use Rust code?

* Completed
** Replace stagefright's MP4 metadata parser with mp4parse crate (shipped in Firefox 48)
** Replace uconv with encoding-rs: {{bug|1261841}} (shipping in Firefox 56)
* In progress
** URL parser: {{bug|url-oxidation}}
** CSS style calculation (from Servo): {{bug|stylo}}
** WebM demuxer: {{bug|1267492}}
** WebRender (from Servo): {{bug|webrender}}
** Audio remoting for Linux: {{bug|1362220}}
** SDP parsing in WebRTC {{bug|1365792}}
* Proposed
** Replace the XML parser
** Replace the preferences module
** Replace the telemetry module(?)
** Share media playback stack with Servo(?)
** Replace DOM serializers (XML, HTML for Save As.., plain text)

What is the high-level status of things?
* We are actively adding new code modules written in Rust to Firefox.
* Rust has been *required* on all platforms since Firefox 54.

== Raw Rust code (lives in m-c) blockers ==

* Top-level metabug {{bug|oxidation}}
* Android support {{bug|1220307}}
* Linux distro support for Rust [https://internals.rust-lang.org/t/perfecting-rust-packaging/2623]
* Need to improve call stacks {{bug|1268328 }}

== Cargo / GitHub blockers ==

* Tracking bug {{bug|1231764}}
* Improve working with vendored Cargo crates [https://github.com/rust-lang/cargo/issues/1926] [https://github.com/rust-lang/cargo/issues/2212]

== Rust / Cargo nice-to-haves ==

* Per-crate integer overflow checking [https://github.com/rust-lang/cargo/issues/2262]
* Artifact caching [https://github.com/rust-lang/cargo/issues/1997]

== Meetings ==

* Mozlando [https://github.com/servo/servo/wiki/Mozlando-Oxidation]
* Oxidation Nov. 2015 [https://github.com/servo/servo/wiki/Oxidation-2015-11-05]
* Mozlandia [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko]
* Whistler [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko]

Oxidation

2017-07-07T07:36:42Z

Hsivonen: Mention mp4parse

'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code into Gecko and Firefox.

* Tracking: {{bug|oxidation}}
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]
* [https://gecko.readthedocs.io/en/latest/build/buildsystem/rust.html Build System Documentation]

Which components will use Rust code?

* Completed
** Replace MP4 metadata parser with mp4parse crate (shipped in Firefox 48)
** Replace uconv with encoding-rs: {{bug|1261841}} (shipping in Firefox 56)
* In progress
** URL parser: {{bug|url-oxidation}}
** CSS style calculation (from Servo): {{bug|stylo}}
** WebM demuxer: {{bug|1267492}}
** WebRender (from Servo): {{bug|webrender}}
** Audio remoting for Linux: {{bug|1362220}}
** SDP parsing in WebRTC {{bug|1365792}}
* Proposed
** Replace the XML parser
** Replace the preferences module
** Replace the telemetry module(?)
** Share media playback stack with Servo(?)
** Replace DOM serializers (XML, HTML for Save As.., plain text)

What is the high-level status of things?
* We are actively adding new code modules written in Rust to Firefox.
* Rust has been *required* on all platforms since Firefox 54.

== Raw Rust code (lives in m-c) blockers ==

* Top-level metabug {{bug|oxidation}}
* Android support {{bug|1220307}}
* Linux distro support for Rust [https://internals.rust-lang.org/t/perfecting-rust-packaging/2623]
* Need to improve call stacks {{bug|1268328 }}

== Cargo / GitHub blockers ==

* Tracking bug {{bug|1231764}}
* Improve working with vendored Cargo crates [https://github.com/rust-lang/cargo/issues/1926] [https://github.com/rust-lang/cargo/issues/2212]

== Rust / Cargo nice-to-haves ==

* Per-crate integer overflow checking [https://github.com/rust-lang/cargo/issues/2262]
* Artifact caching [https://github.com/rust-lang/cargo/issues/1997]

== Meetings ==

* Mozlando [https://github.com/servo/servo/wiki/Mozlando-Oxidation]
* Oxidation Nov. 2015 [https://github.com/servo/servo/wiki/Oxidation-2015-11-05]
* Mozlandia [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko]
* Whistler [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko]

Oxidation

2017-07-07T07:31:39Z

Hsivonen: Mention serializers

'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code into Gecko and Firefox.

* Tracking: {{bug|oxidation}}
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]
* [https://gecko.readthedocs.io/en/latest/build/buildsystem/rust.html Build System Documentation]

Which components will use Rust code?

* Completed
** Replace uconv with encoding-rs: {{bug|1261841}} (shipping in Firefox 56)
* In progress
** URL parser: {{bug|url-oxidation}}
** CSS style calculation (from Servo): {{bug|stylo}}
** WebM demuxer: {{bug|1267492}}
** WebRender (from Servo): {{bug|webrender}}
** Audio remoting for Linux: {{bug|1362220}}
** SDP parsing in WebRTC {{bug|1365792}}
* Proposed
** Replace the XML parser
** Replace the preferences module
** Replace the telemetry module(?)
** Share media playback stack with Servo(?)
** Replace DOM serializers (XML, HTML for Save As.., plain text)

What is the high-level status of things?
* We are actively adding new code modules written in Rust to Firefox.
* Rust has been *required* on all platforms since Firefox 54.

== Raw Rust code (lives in m-c) blockers ==

* Top-level metabug {{bug|oxidation}}
* Android support {{bug|1220307}}
* Linux distro support for Rust [https://internals.rust-lang.org/t/perfecting-rust-packaging/2623]
* Need to improve call stacks {{bug|1268328 }}

== Cargo / GitHub blockers ==

* Tracking bug {{bug|1231764}}
* Improve working with vendored Cargo crates [https://github.com/rust-lang/cargo/issues/1926] [https://github.com/rust-lang/cargo/issues/2212]

== Rust / Cargo nice-to-haves ==

* Per-crate integer overflow checking [https://github.com/rust-lang/cargo/issues/2262]
* Artifact caching [https://github.com/rust-lang/cargo/issues/1997]

== Meetings ==

* Mozlando [https://github.com/servo/servo/wiki/Mozlando-Oxidation]
* Oxidation Nov. 2015 [https://github.com/servo/servo/wiki/Oxidation-2015-11-05]
* Mozlandia [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko]
* Whistler [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko]

Modules/Core

2017-04-13T07:48:53Z

Hsivonen: Add William Chen as HTML Parser peer

<noinclude>
'''Only module owners may edit this page.'''

They may:

* update any information about their module except the name of the owner
* add or remove sub-modules
* change the owner of a sub-module
* add emeritus owners or peers

Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].
</noinclude>
{{Module
|name=Accessibility
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe]
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal]
|peersemeritus=[mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan
|group=dev-accessibility
|source_dirs=accessible/
|url=http://www.mozilla.org/access/
|components=Core::Disability Access APIs
}}

{{Module
|name=Browser WebAPI
|description=Web API for rendering apps, browser windows and widgets.
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]
|group=dev-webapi
|source_dirs=dom/browser-element/
|url=
|components=Core::DOM
}}

{{Module
|name=Build and Release Tools
|description=Tools related to build and release automation and configuration of release builds.
|owner=[mailto:nthomas@mozilla.com Nick Thomas]
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]
|group=release-engineering
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/
|url=https://wiki.mozilla.org/ReleaseEngineering
|components=Release Engineering::*
}}

{{Module
|name=Build Config
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:cmanchester@mozilla.com Chris Manchester](:chmanchester), [mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj), [mailto:rgiles@mozilla.com Ralph Giles] (:rillian)
|ownersemeritus=Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]),
|group=dev-builds
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/
|url=http://www.mozilla.org/build/
|components=Core::Build Config
}}

{{Module
|name=Code Analysis and Debugging Tools
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=
|group=dev-performance
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/,
|url=
|components=
}}

{{Module
|name=Content HTTP Headers
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)
|owner=[mailto:gerv@mozilla.org Gervase Markham]
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]
|group=dev-platform
|source_dirs=
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference
|components=Core::Networking: HTTP
}}

{{Module
|name=Content Security
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI) and CORS.
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]
|peers=[mailto:francois@mozilla.com François Marier], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:mozilla@sidstamm.com Sid Stamm]
|group=dev-security
|source_dirs=dom/security
|components=Core::DOM: Security
}}

{{Module
|name=Cookies and Permissions
|description=
|owner=Monica Chew
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-tech-network
|source_dirs=extensions/cookie/, netwerk/cookie/
|url=
|components=Core::Networking: Cookies
}}
{{Module
|name=Cycle Collector
|description=Code to break and collect objects within reference cycles
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]
|peers=Peter Van der Beken, Olli Pettay, David Baron
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers
|components=Core::XPCOM
|group=dev-platform
}}
{{Module
|name=C++/Rust usage, tools, and style
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden]
|source_dirs=non-third-party C++ and Rust code in the tree
|components=Various components
|group=dev-platform
}}
{{Module
|name=docshell
|description=
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]
|group=dev-tech-layout
|source_dirs=docshell/, uriloader/
|url=
|components=Core::Document Navigation
}}

{{Module
|name=Device Storage
|description=Support for the device storage API
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands] (:dhylands), [mailto:jvarga@mozilla.com Jan Varga] (:janv)
|peers=
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner] (:dougt)
|group=dev-tech-dom
|source_dirs=dom/devicestorage/, dom/interfaces/devicestorage/
|url=https://developer.mozilla.org/en-US/docs/WebAPI/Device_Storage
|components=Core::DOM: Device Interfaces
}}

{{Module
|name=Document Object Model
|description=
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri (still active, but slower to respond than previously)], [mailto:me@kylehuey.com Kyle Huey], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:billm@mozilla.com Bill McCloskey], [mailto:kyle@nonpolynomial.com Kyle Machulis]
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar]
|group=dev-tech-dom
|source_dirs=dom/*, except directories covered by other modules
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML
}}

{{Module
|name=Event Handling
|description=DOM Events and Event Handling
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]
|group=dev-platform
|source_dirs=dom/events and event handling related code elsewhere
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM: Events, Core::Event Handling
}}

{{Module
|name=Web Workers
|description=
|owner=[mailto:bent.mozilla@gmail.com Ben Turner]
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:baku@mozilla.com Andrea Marchesini], [mailto:bkelly@mozilla.com Ben Kelly]
|group=dev-platform
|source_dirs=dom/workers/
|url=https://developer.mozilla.org/En/Using_web_workers
|components=Core::DOM: Workers
}}

{{Module
|name=IndexedDB
|description=
|owner=[mailto:bent.mozilla@gmail.com Ben Turner]
|peers=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:jvarga@mozilla.com Jan Varga], [mailto:btseng@mozilla.com Bevis Tseng]
|group=dev-platform
|source_dirs=dom/indexedDB/
|url=https://developer.mozilla.org/en/IndexedDB
|components=Core::DOM: IndexedDB
}}

{{Module
|name=Editor
|description=
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:ayg@aryeh.name Aryeh Gregor]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

{{Module
|name=Embedding
|description=Gecko embedding APIs and frameworks
|owner=[mailto:myk@mykzilla.org Myk Melez]
|ownersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:doug.turner@gmail.com Doug Turner]
|peers=[mailto:bdahl@mozilla.com Brendan Dahl], [mailto:tbsaunde@tbsaunde.org Trevor Saunders]
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jstenback@gmail.com Johnny Stenback]
|group=dev-platform
|source_dirs=embedding/
|url=
|components=Core::Embedding: APIs
}}

{{Module
|name=Find As You Type
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.
|owner=
|peers=
|group=dev-accessibility
|source_dirs=extensions/typeaheadfind/
|url=http://www.mozilla.org/access/type-ahead/
|components=
}}

{{Module
|name=Gecko Profiler
|description=Gecko's built-in profiler
|owner=[mailto:mstange@themasta.com Markus Stange]
|peers=[mailto:nnethercote@mozilla.com Nicholas Nethercote], [mailto:jseward@mozilla.com Julian Seward] (LUL), [mailto:kvijayan@mozilla.com Kannan Vijayan] (JS integration), [mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer), [mailto:b56girard@gmail.com Benoit Girard].
|group=dev-platform
|source_dirs=tools/profiler/
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
|components=Core::Gecko Profiler
}}

{{Module
|name=Geolocation
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.
|owner=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner], Garvan Keeley
|peers=
|group=dev-tech-dom
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi
|url=https://developer.mozilla.org/En/Using_geolocation
|components=Core::Geolocation
}}

{{Module
|name=Global Key Bindings
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.
|owner=Aaron Leventhal
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|group=dev-accessibility
|source_dirs=dom/xbl/builtin/
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
|components=Core::Keyboard: Navigation
}}

{{Module
|name=Graphics
|description=Mozilla graphics API
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D, Skia), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord], [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman], [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson]
|group=dev-platform
|source_dirs=gfx/, dom/canvas/
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL
}}

{{Module
|name=APZ (Graphics submodule)
|description=Asynchronous panning and zooming
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:dvander@mozilla.com David Anderson], [mailto:mstange@mozilla.com Markus Stange]
|group=dev-platform
|source=gfx/layers/apz
|url=https://wiki.mozilla.org/Platform/GFX/APZ
|components=Core::Panning and Zooming
}}

{{Module
|name=Moz2D (Graphics submodule)
|description=Platform independent 2D graphics API
|owner=[mailto:bschouten@mozilla.com Bas Schouten]
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@mozilla.com Jonathan Watt]
|group=dev-platform
|source=gfx/2d
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D
|components=Core::Graphics
}}

{{Module
|name=Legacy HTML Parser
|description=
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]
|source_dirs=parser/htmlparser
|url=http://www.mozilla.org/newlayout/doc/parser.html
|components=Core::HTML: Parser
}}

{{Module
|name=HAL
|description=Hardware Abstraction Layer
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]
|group=dev-platform
|source_dirs=hal/
|components=Core::Hardware Abstraction Layer (HAL)
}}

{{Module
|name=HTML Parser
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]
|peers=[mailto:wchen@mozilla.com William Chen]
|group=dev-platform
|source_dirs=parser/html
|url=http://about.validator.nu/
|components=Core::HTML: Parser
}}

{{Module
|name=I18N Library
|description=
|owner=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura]
|group=dev-i18n
|source_dirs=intl/
|url=http://mozilla.org/projects/intl/index.html
|components=Core::Internationalization
}}

{{Module
|name=ImageLib
|description=
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:seth.bugzilla@blackhail.net Seth Fowler]
|group=dev-platform
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/
|url=
|components=Core::ImageLib
}}

{{Module
|name=IPC
|description=Message-passing between threads and processes
|owner=[mailto:wmccloskey@mozilla.com Bill McCloskey]
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:jld@mozilla.com Jed Davis], [mailto:kchen@mozilla.com Kan-Ru Chen]
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

{{Module
|name=JavaScript
|description=JavaScript engine (SpiderMonkey)
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:jwalden@mit.edu Jeff Walden], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], [mailto:efaust@mozilla.com Eric Faust], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], Andreas Gal
|group=dev-tech-js-engine
|source_dirs=js/src
|url=http://www.mozilla.org/js/spidermonkey,
http://developer.mozilla.org/en/docs/About_JavaScript
|components=Core::JavaScript Engine
}}

{{Module
|name=JavaScript JIT
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]
|group=dev-tech-js-engine-internals
|source_dirs=js/src/jit
|url=http://www.mozilla.org/js/spidermonkey
|components=Core::JavaScript Engine: JIT
}}

{{Module
|name=JavaScript Debugger Backend
|description=JavaScript debugging hooks
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]
|group=dev-apps-js-debugger
|source_dirs=js/jsd/
|url=http://www.mozilla.org/js/jsd
|components=Other Applications::Venkman JS Debugger
}}

{{Module
|name=jsat
|description=Javascript screen reader that is used in Android and B2G
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]
|group=dev-accessibility
|source_dirs=accessible/jsat/
|url=http://www.mozilla.org/access/
|components=Core::Disability Access APIs
}}

{{Module
|name=js-ctypes
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bobbyholley@gmail.com Bobby Holley]
|group=dev-tech-js-engine
|source_dirs=js/src/ctypes/
|url=https://wiki.mozilla.org/JSctypes
|components=Core::js-ctypes
}}

{{Module
|name=js-tests
|description=JavaScript test suite
|owner=[mailto:bclary@bclary.com Bob Clary]
|peers=
|group=dev-tech-js-engine
|source_dirs=js/tests/
|url=http://www.mozilla.org/js/tests/library.html
|components=
}}

{{Module
|name=Layout Engine
|description=rendering tree construction, layout (reflow), etc.
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan]
|group=dev-tech-layout
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/
|url=http://mozilla.org/newlayout/doc/ ,
http://lxr.mozilla.org/mozilla/source/layout/doc/
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Print Preview, Core::Printing: Output
}}

{{Module
|name=libjar
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).
|owner=[mailto:mwu@mozilla.com Michael Wu]
|peers=[mailto:aklotz@mozilla.com Aaron Klotz]
|group=dev-platform
|source_dirs=modules/libjar
|url=
|components=
}}

{{Module
|name=MathML
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]
|group=dev-tech-mathml
|source_dirs=layout/mathml/
|url=http://www.mozilla.org/projects/mathml/
|components=Core::MathML
}}

{{Module
|name=Media Playback
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).
|owner=[mailto:cpearce@mozilla.com Chris Pearce]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peers=[mailto:ajones@mozilla.com Anthony Jones], [mailto:kinetik@flim.org Matthew Gregan], [mailto:eflores@mozilla.com Edwin Flores], [mailto:jyavenard@mozilla.com Jean-Yves Avenard], [mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:rgiles@mozilla.com Ralph Giles], [mailto:jwwang@mozilla.com JW Wang]
|group=dev-media
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/
|url=
|components=Core::Audio/Video
}}

{{Module
|name=Media Transport
|description=Pluggable transport for real-time media
|owner=[mailto:ekr@rtfm.com Eric Rescorla]
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|group=dev-media
|source_dirs=media/mtransport
|url=
|components=Core::WebRTC::Networking
}}

{{Module
|name=Memory Allocator
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-platform
|source_dirs=memory/
|components=Core::DMD, Core::jemalloc
}}

{{Module
|name=mfbt
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).
|owner=[mailto:jwalden@mit.edu Jeff Walden]
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]
|group=dev-platform
|source_dirs=mfbt/
|url=
|components=Core::MFBT
}}

{{Module
|name=mozApps API & UI
|description=Implementation of the navigator.mozApps API
|owner=[mailto:fabrice@mozilla.com Fabrice Desré], [mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:myk@mozilla.org Myk Melez], [mailto:mar.castelluccio@studenti.unina.it Marco Castelluccio], [mailto:ferjmoreno@gmail.com Fernando Jiménez]
|group=dev-webapi
|source_dirs=dom/apps/, dom/interfaces/apps, product specific files implementing UI hooks.
|url=
|components=Core::DOM: Apps
}}

{{Module
|name=Mozglue
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android)
|group=dev-platform
|source_dirs=mozglue/
|components=Core::mozglue
}}

{{Module
|name=mozilla-toplevel
|description=The top level directory for the mozilla tree.
|owner=[mailto:brendan@mozilla.org Brendan Eich]
|peers=
|group=
|source_dirs=tools/README
|url=
|components=
}}

{{Module
|name=Necko
|description=The Mozilla Networking Library
|owner=[mailto:mcmanus@ducksong.com Patrick McManus]
|peers= [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:dd.mozilla@gmail.com Dragana Damjanovic ],[mailto:valentin.gosu@gmail.com Valentin Gosu],[mailto:daniel@haxx.se Daniel Stenberg ]
|peersemeritus= [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sworkman@mozilla.com Steve Workman], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-network
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets
}}

{{Module
|name=NSPR
|description=Netscape Portable Runtime
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]
|peers=[mailto:wtc@google.com Wan-Teh Chang], [mailto:mh@glandium.org Mike Hommey], [mailto:kaie@kuix.de Kai Engert]
|group=dev-tech-nspr
|source_dirs=nsprpub/
|url=http://www.mozilla.org/projects/nspr/
http://www.mozilla.org/projects/nspr/reference/html/
http://www.mozilla.org/projects/nspr/release-notes/
|components=NSPR
}}

{{Module
|name=PDF
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.
|owner=Chris Jones, Andreas Gal
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]
|group=dev-platform
|source_dirs=media/pdf/
|url=https://github.com/mozilla/pdf.js
|components=Core::PDF
}}

{{Module
|name=Plugins
|description= NPAPI Plugin support.
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:joshmoz@gmail.com Josh Aas]
|peersemeritus=[mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback]
|group=
|source_dirs=dom/plugins/, modules/plugin/
|url=https://wiki.mozilla.org/Plugins
|components=Core::Plug-ins
}}

{{Module
|name=Preferences
|description=Preference library
|owner=
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|group=dev-platform
|source_dirs=modules/libpref/
|url=
|components=Core::Preferences: Backend
}}

{{Module
|name=Private Browsing
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:josh@joshmatthews.net Josh Matthews]
|group=dev-platform
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code.
|url=https://wiki.mozilla.org/Private_Browsing
|components=Firefox::Private Browsing
}}

{{Module
|name=Privilege Manager
|description="caps"
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]
|group=dev-tech-dom
|source_dirs=caps/
|url=http://www.mozilla.org/projects/security/components/index.html
|components=Core::Security: CAPS
}}

{{Module
|name=Push Notifications
|description=Push is a way for application developers to send messages to their web applications.
|owners=
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:kcambridge@mozilla.com Kit Cambridge], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]
|group=
|source_dirs=dom/push, dom/simplepush
|url=
|components=
}}

{{Module
|name=PyXPCOM
|description=The Python to XPCOM bridge.
|owner=Todd Whiteman
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]
|group=
|source_dirs=extension/python
|url=https://developer.mozilla.org/en/PyXPCOM
|components=
}}

{{Module
|name=RDF
|description=
|owner=[mailto:axel@pike.org Axel Hecht]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|group=dev-tech-rdf
|source_dirs=rdf/
|url=http://www.mozilla.org/rdf/doc/
|components=Core::RDF
}}

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:ttaubert@mozilla.com Tim Taubert]
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:wtc@google.com Wan-Teh Chang]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com David Keeler]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM, Core::Security: UI
}}

{{Module
|name=Static analysis & rewriting for C++
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:michael@thelayzells.com Michael Layzell], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas]
|group=dev-platform
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools
|url=
|components=Core::Rewriting & Analysis
}}
{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:cam@mcc.id.au Cameron McCormack]
|group=dev-tech-layout
|source_dirs=layout/style/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=Tamarin
|description=VM for ActionScript and JavaScript
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]
|group=dev-tech-js-engine
|source_dirs=js/tamarin
|url=http://www.mozilla.org/projects/tamarin/
http://wiki.mozilla.org/tamarin/
http://hg.mozilla.org/tamarin-central/
http://hg.mozilla.org/tamarin-tracing/
|components=Tamarin
}}

{{Module
|name=Test Harness
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill, Marionette, Firefox UI Tests. Requests for new harnesses should go to Testing::General.
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), Rob Campbell (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (Marionette, Firefox UI tests), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette) [mailto:dminor@mozilla.com Dan Minor], [mailto:mjzffr@gmail.com Maja Frydrychowicz] (Marionette, Firefox UI tests),

|group=dev-quality
|source_dirs=/testing
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js
}}

{{Module
|name=Testing Infrastructure
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker
|owner=[mailto:jmaher@mozilla.com Joel Maher]
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], Rob Campbell, [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]
|group=dev-quality
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::Infrastructure
}}

{{Module
|name=JS Marionette
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye>
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk>
|source_dirs=gaia/tests/jsmarionette
|components=Testing::JSMarionette
|group=dev-gaia
}}

{{Module
|name=XPCShell Test Harness
|description=The XPCShell Harness
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]
|peers=[mailto:jmaher@mozilla.com Joel Maher]
|source_dirs=testing/xpcshell
|components=Testing::XPCShell Harness
}}

{{Module
|name=Update Service
|description=server code for Mozilla Update services (aus, addons, pfs)
|owner=Mike Morgan
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]
|group=dev-amo
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/
|url=http://wiki.mozilla.org/wiki/AMO
|components=AUS::Administration, AUS::Systems
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:mstange@themasta.com Markus Stange]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:padenot@mozilla.com Paul Adenot]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=Web Painting
|description=painting, display lists, and layer construction
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange]
|group=dev-tech-layout
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses
|url=http://mozilla.org/newlayout/doc/ ,
http://lxr.mozilla.org/mozilla/source/layout/doc/
|components=Core::Layout: Web Painting
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=N/A (see submodules "WebRTC Media" and "WebRTC Signaling")
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC
}}

{{Module
|name=Widget
|description=
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter],
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup
}}

{{Module
|name=Widget - Android
|description=The Android Port
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]
|peers=[mailto:jwillcox@mozilla.com James Willcox]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=supported X widgetry and gfx
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - OS X
|description= Gecko's OS X compatibility layer.
|owner=[mailto:mstange@themasta.com Markus Stange]
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widgets and desktop integration
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:jmathies@mozilla.com Jim Mathies]
|peersemeritus=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XBL
|description=eXtensible Binding Language
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xbl
|source_dirs=dom/xbl/
|url=http://www.mozilla.org/projects/xbl/
|components=Core::XBL
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|peers=[https://mozillians.org/en-US/u/bsmedberg/ Benjamin Smedberg], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:me@kylehuey.com Kyle Huey]
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XPInstall
|description=
|owner=[mailto:dveditz@mozilla.com Dan Veditz]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|group=dev-tech-xpinstall
|source_dirs=xpinstall/
|url=
|components=Core::Installer: XPInstall Engine
}}

{{Module
|name=xptcall
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.
|owner=
|ownersemeritus=[mailto:timeless@mozdev.org Josh 'timeless' Soref]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]
|group=dev-xpcom
|source_dirs=xpcom/reflect/xptcall/
|url=http://www.mozilla.org/scriptable/xptcall-faq.html
|components=
}}

{{Module
|name=XPToolkit
|description=Cross-platform user interface toolkit
|owner=
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]
|group=dev-tech-xul
|source_dirs=dom/xul/, layout/xul/
|url=http://www.mozilla.org/xpfe/
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=XTF
|description=eXtensible Tag Framework
|owner=
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xbl
|source_dirs=content/xtf/, layout/xtf/
|url=http://www.croczilla.com/bits_and_pieces/xtf/
|components=Core::XTF
}}

{{Module
|name=Sandboxing
|description=Cross platform sandboxing
|owner=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|peers=[mailto:bowen@mozilla.com Bob Owen], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes], [mailto:gDestuynder@mozilla.com Guillaume Destuynder], [mailto:jld@mozilla.com Jed Davis]
|group=dev-platform
|source_dirs=security/sandbox
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bowen@mozilla.com Bob Owen]
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes], [mailto:jimm@mozilla.com Jim Mathies]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]
|peers=
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux & B2G
|description=Sandboxing for the Linux & B2G platforms
|owner=[mailto:jhector@mozilla.com Julian Hector]
|peers=[mailto:jld@mozilla.com Jed Davis] [mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]
|peers=Same as Build Config
|group=dev-builds
|components=Core::Build Config
}}

{{Module
|name=WebRTC Media
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:jib@mozilla.com Jan-Ivar Bruaroey]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc, /dom/media/webrtc
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Audio/Video)
}}

{{Module
|name=WebRTC Signaling
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling
|owner=[mailto:bcampen@mozilla.com Byron Campen]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc/signaling/
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Signaling)
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::File Handling
Core::Find Backend
Core::Gecko Profiler
Core::General
Core::HTML: Form Submission
Core::History: Global
Core::Image Blocking
Core::JavaScript Debugging APIs
Core::Localization
Core::Nanojit
Core::Networking: Domain Lists
Core::Print Preview
Core::Printing: Output
Core::Printing: Setup
Core::Profile: BackEnd
Core::Profile: Migration
Core::Profile: Roaming
Core::QuickLaunch (AKA turbo mode)
Core::Rewriting and Analysis
Core::Selection
Core::Serializers
Core::Spelling checker
Core::Tracking
Core::Web Services
Core::WebDAV
Core::Widget: OS/2
Core::Widget: Photon
Core::X-remote
Core::XForms
Core::XUL
</pre>
</noinclude>

WebAPI/DesignGuidelines

2014-08-26T10:04:00Z

Hsivonen: /* Design considerations */ Avoid "ask the user" as an attack mitigation mechanism when possible

<div style="margin: 1em 0px; border: 2px solid orange; padding: 1em; background-color: orange; text-align: center;">'''NOTE'''
<div style="font-size:x-small">This is a work in progress.</div></div>

Designing APIs for the web is not an easy task. Here are some suggestions to help.

==Preparation==
* if this is (one of) your first web APIs, keep your scope narrow.
** with some experience, you'll see fundamental issues with the web platform for which you can propose fixes!
** if this is your first web API, work with a co-editor that has bandwidth to help you.
* publicly discuss & document use-cases, motivations, and design sketches early, often, and widely (e.g. [[IRC]], wiki (here on WikiMo or http://wiki.whatwg.org/ ), applicable W3C/WHATWG lists, [https://lists.mozilla.org/listinfo/dev-webapi dev-webapi], [https://lists.mozilla.org/listinfo/dev-platform dev-platform], [https://lists.mozilla.org/listinfo/dev-gaia dev-gaia], blogs, Twitter, GitHub issues, etc.).
* avoid scope creep by avoiding trying to fix unrelated problems.
** For an example of what NOT to do, see Google's "Web Intents", which scope creeped to try solve all data-to-code-or-service binding/launching problems.
* iterate and only expand your scope as new features are justified by documented use-cases.
* start with '''use cases and requirements'''.
* collect currently shipping, available for use '''examples from other platforms''' (ex. Android, iOS).
* determine and document how the existence of these technologies impact markets (ex. lots of uses in the Google Play store).
* find articles, blog post comments, Stack Overflow entries showing that people want this feature on the web.
* if possible, document how web developers are working around the missing functionality with polyfills and other mechanisms and the drawbacks of this approach ([http://usecases.responsiveimages.org/#limitations-of-current-techniques responsive images example of this]).
* use the above to '''document a need for the API beyond "it would be cool"'''.
* document that existing web technologies are not sufficient and that users and developers are being negatively affected by the lack of this feature on the web.
* show that there is enough consensus making this a good candidate for standardization (the <picture> element did this).
** find developers that would make use of this.
** if you can't find any interested parties then this may not be the right time to standardize your API, keep developing it on an open wiki page incrementally so that others that may be interested might find it in the future.
* document potential abuse cases and attack vectors.
** you don't have to know how to address the concerns, just document them.
** ask someone to help you find them.
** example: http://w3c-webmob.github.io/wake-lock-use-cases/#potential-for-abuse.
* take these use cases and requirement to a standards body where people can help you format it into a suitable document such as:
** http://w3c-webmob.github.io/wake-lock-use-cases.
** http://w3c-webmob.github.io/netinfo-usecases/.
* '''expect your uses cases and requirements to evolve''' as you attempt to standardize.
* build consensus.
** find interested parties who say they'll use this functionality; '''expressions of interest are critical'''.
** find allies at browser vendors.
** http://specifiction.org/.
** https://openwebapps.uservoice.com/.

==Standardizing a Feature==
* create a lightweight proposal but be prepared for criticism and expect to make changes:
** Create a CSS, HTML element, and JavaScript version: consider the problem you are trying to solve from multiple angles (even if the CSS or HTML solutions end up being unworkable).
* '''keep your proposal short'''.
* encourage counter proposals.
** multiple proposals are good so don't be attached to your design in case it doesn't survive.
** solving the problem you set out to solve is more important than your proposed API getting standardized.
* in advance, answer questions you anticipate and point people to the answers when they ask related questions.
* if you don't get responses, ask people you know who are more well-known in that community.
* "it takes a village to raise an API".

==Specification work==
If you get the OK from the standards community, go forth and write a specification.
* have your work in a public location where people can comment and provide patches.
** Etherpad, Wiki (WikiMo or http://wiki.whatwg.org/ ), GitHub repo, Google Doc, etc. Anything that's collaborative.
* actual standardization decisions will be made by relevant organization.
** ex. a W3C Working Group, a W3C Community Group, the WHATWG, the IETF, etc.
** See [[Standards]] for a list of standards groups and organizations.
* follow Mozilla's [[WebAPI/ExposureGuidelines|API exposure guidelines]] (notably sending "Intent to implement" emails).
* carefully follow the processes of the standards organization within which you are working.
** there are often legal reasons for these processes.

==Design considerations==
* put users first, especially their privacy and security of their data and hardware.
* don't fight the web's security model.
* build on top of web standards.
** use common idioms.
** don't build on top of features specific to one browser.
* if you are extending the algorithms of another specification, request that the spec you are extending highlights to its readers the points your spec extends/plugs into
* document and standardize attack vector mitigations so they're done consistently across implementations.
** if the attacks can be mitigated either by asking the user or by designing the feature so that there's no need to ask the user, prefer not asking the user.
* attempt to avoid "prompt fatigue" (e.g. don't skirt security concerns by prompting to allow the web content to do something as users will have difficulty reading and interpreting the associated risks).
* ensure the API is "webby".
** if you're coming from a Java, C, or C++ background, you may want to speak with JavaScript people.
* researching underlying implementations of what you'll be exposing to the web may help you design something that will ease implementation for the web.
* work with the strengths of the web and JavaScript (e.g. IndexedDB works directly with JS objects and doesn't require serialization to SQL primitives).
* use new features instead of old ones (e.g. Promises instead of DOMRequests, WebIDL, ...).
** But there is nothing wrong with events and such.
** Don't use new features just for the sake of being cool and hip. Use them when they make sense.
* the design of APIs only exposed to privileged or certified apps is less important to get right the first time than those that will be exposed to the web at large but if this route is chosen, future standardization efforts will be hampered.
* standardization is sometimes not necessary for APIs designed for very narrow use cases or those that have no hope of being implemented by other UA vendors.
* sometimes it makes sense to limit API exposure to authenticated origins (https:) only.
* bringing existing technologies to the web gives a chance to mask details that aren't of interest or important to web developers.
* web APIs are "forever" so be very careful with what you expose to the web! maintain web compatibility!
* Be consistent. No special cases in the APIs.

==Tips==
* find someone who has done this before to mentor you on your first attempt.
* many proposals will fail to get traction and materialize into a standard but don't be upset and try again in the future.
* treat people asking questions and those trying to help with respect.
* collect responses given on mailing lists, via IRC, etc. into your use case documents, FAQs, explainers, etc.; don't rely on people looking through archives.

==Resources==
* http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
* https://github.com/w3ctag/promises-guide
* http://annevankesteren.nl/2014/08/asynchronicity
* http://annevankesteren.nl/2014/03/contributing-to-standards
* http://annevankesteren.nl/2014/02/monkey-patch
* [http://tantek.com/2011/168/b1/practices-good-open-web-standards-development 10 Practices for Good Open Web Standards Development]
* [http://dbaron.org/log/2007-03#e20070325a Problems with versioning, part 1: open environments]

== See Also ==
* [[Standards]]

WebAPI/DesignGuidelines

2014-08-26T10:00:52Z

Hsivonen: /* Design considerations */ Secure origins are apparently called authenticated origins now

<div style="margin: 1em 0px; border: 2px solid orange; padding: 1em; background-color: orange; text-align: center;">'''NOTE'''
<div style="font-size:x-small">This is a work in progress.</div></div>

Designing APIs for the web is not an easy task. Here are some suggestions to help.

==Preparation==
* if this is (one of) your first web APIs, keep your scope narrow.
** with some experience, you'll see fundamental issues with the web platform for which you can propose fixes!
** if this is your first web API, work with a co-editor that has bandwidth to help you.
* publicly discuss & document use-cases, motivations, and design sketches early, often, and widely (e.g. [[IRC]], wiki (here on WikiMo or http://wiki.whatwg.org/ ), applicable W3C/WHATWG lists, [https://lists.mozilla.org/listinfo/dev-webapi dev-webapi], [https://lists.mozilla.org/listinfo/dev-platform dev-platform], [https://lists.mozilla.org/listinfo/dev-gaia dev-gaia], blogs, Twitter, GitHub issues, etc.).
* avoid scope creep by avoiding trying to fix unrelated problems.
** For an example of what NOT to do, see Google's "Web Intents", which scope creeped to try solve all data-to-code-or-service binding/launching problems.
* iterate and only expand your scope as new features are justified by documented use-cases.
* start with '''use cases and requirements'''.
* collect currently shipping, available for use '''examples from other platforms''' (ex. Android, iOS).
* determine and document how the existence of these technologies impact markets (ex. lots of uses in the Google Play store).
* find articles, blog post comments, Stack Overflow entries showing that people want this feature on the web.
* if possible, document how web developers are working around the missing functionality with polyfills and other mechanisms and the drawbacks of this approach ([http://usecases.responsiveimages.org/#limitations-of-current-techniques responsive images example of this]).
* use the above to '''document a need for the API beyond "it would be cool"'''.
* document that existing web technologies are not sufficient and that users and developers are being negatively affected by the lack of this feature on the web.
* show that there is enough consensus making this a good candidate for standardization (the <picture> element did this).
** find developers that would make use of this.
** if you can't find any interested parties then this may not be the right time to standardize your API, keep developing it on an open wiki page incrementally so that others that may be interested might find it in the future.
* document potential abuse cases and attack vectors.
** you don't have to know how to address the concerns, just document them.
** ask someone to help you find them.
** example: http://w3c-webmob.github.io/wake-lock-use-cases/#potential-for-abuse.
* take these use cases and requirement to a standards body where people can help you format it into a suitable document such as:
** http://w3c-webmob.github.io/wake-lock-use-cases.
** http://w3c-webmob.github.io/netinfo-usecases/.
* '''expect your uses cases and requirements to evolve''' as you attempt to standardize.
* build consensus.
** find interested parties who say they'll use this functionality; '''expressions of interest are critical'''.
** find allies at browser vendors.
** http://specifiction.org/.
** https://openwebapps.uservoice.com/.

==Standardizing a Feature==
* create a lightweight proposal but be prepared for criticism and expect to make changes:
** Create a CSS, HTML element, and JavaScript version: consider the problem you are trying to solve from multiple angles (even if the CSS or HTML solutions end up being unworkable).
* '''keep your proposal short'''.
* encourage counter proposals.
** multiple proposals are good so don't be attached to your design in case it doesn't survive.
** solving the problem you set out to solve is more important than your proposed API getting standardized.
* in advance, answer questions you anticipate and point people to the answers when they ask related questions.
* if you don't get responses, ask people you know who are more well-known in that community.
* "it takes a village to raise an API".

==Specification work==
If you get the OK from the standards community, go forth and write a specification.
* have your work in a public location where people can comment and provide patches.
** Etherpad, Wiki (WikiMo or http://wiki.whatwg.org/ ), GitHub repo, Google Doc, etc. Anything that's collaborative.
* actual standardization decisions will be made by relevant organization.
** ex. a W3C Working Group, a W3C Community Group, the WHATWG, the IETF, etc.
** See [[Standards]] for a list of standards groups and organizations.
* follow Mozilla's [[WebAPI/ExposureGuidelines|API exposure guidelines]] (notably sending "Intent to implement" emails).
* carefully follow the processes of the standards organization within which you are working.
** there are often legal reasons for these processes.

==Design considerations==
* put users first, especially their privacy and security of their data and hardware.
* don't fight the web's security model.
* build on top of web standards.
** use common idioms.
** don't build on top of features specific to one browser.
* if you are extending the algorithms of another specification, request that the spec you are extending highlights to its readers the points your spec extends/plugs into
* document and standardize attack vector mitigations so they're done consistently across implementations.
* attempt to avoid "prompt fatigue" (e.g. don't skirt security concerns by prompting to allow the web content to do something as users will have difficulty reading and interpreting the associated risks).
* ensure the API is "webby".
** if you're coming from a Java, C, or C++ background, you may want to speak with JavaScript people.
* researching underlying implementations of what you'll be exposing to the web may help you design something that will ease implementation for the web.
* work with the strengths of the web and JavaScript (e.g. IndexedDB works directly with JS objects and doesn't require serialization to SQL primitives).
* use new features instead of old ones (e.g. Promises instead of DOMRequests, WebIDL, ...).
** But there is nothing wrong with events and such.
** Don't use new features just for the sake of being cool and hip. Use them when they make sense.
* the design of APIs only exposed to privileged or certified apps is less important to get right the first time than those that will be exposed to the web at large but if this route is chosen, future standardization efforts will be hampered.
* standardization is sometimes not necessary for APIs designed for very narrow use cases or those that have no hope of being implemented by other UA vendors.
* sometimes it makes sense to limit API exposure to authenticated origins (https:) only.
* bringing existing technologies to the web gives a chance to mask details that aren't of interest or important to web developers.
* web APIs are "forever" so be very careful with what you expose to the web! maintain web compatibility!
* Be consistent. No special cases in the APIs.

==Tips==
* find someone who has done this before to mentor you on your first attempt.
* many proposals will fail to get traction and materialize into a standard but don't be upset and try again in the future.
* treat people asking questions and those trying to help with respect.
* collect responses given on mailing lists, via IRC, etc. into your use case documents, FAQs, explainers, etc.; don't rely on people looking through archives.

==Resources==
* http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
* https://github.com/w3ctag/promises-guide
* http://annevankesteren.nl/2014/08/asynchronicity
* http://annevankesteren.nl/2014/03/contributing-to-standards
* http://annevankesteren.nl/2014/02/monkey-patch
* [http://tantek.com/2011/168/b1/practices-good-open-web-standards-development 10 Practices for Good Open Web Standards Development]
* [http://dbaron.org/log/2007-03#e20070325a Problems with versioning, part 1: open environments]

== See Also ==
* [[Standards]]

Privacy/Reviews/Telemetry/Measurements

2013-03-05T08:56:05Z

Hsivonen: /* Deployed (In Nightly/Aurora/Beta/Release) */ Document multipart XHR probe removal

__NOTOC__
As [[Platform/Features/Telemetry|Telemetry]] matures and we add more types of data we want to measure, it is important to keep track of what we're gathering and how we're respecting users' privacy. This page lists all of the types of data collected and links to any risk analysis done for the specific measurements.

The current list of histograms collected is in [http://mxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/TelemetryHistograms.h toolkit/components/telemetry/TelemetryHistograms.h]

Instead of full reviews on each major type of measurement, a lightweight risk analysis should be performed to quickly document the question each measurement answers as well as actions taken to minimize privacy risks.

==Histograms==
Histograms that are collected by telemetry are listed in [http://mxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/TelemetryHistograms.h TelemetryHistograms.h], and ones that have review are also listed in the table below.

== Relevant Strings ==
Privacy Policy: [http://www.mozilla.com/en-US/legal/privacy/firefox.html#telemetry http://www.mozilla.com/en-US/legal/privacy/firefox.html#telemetry]

''Opt-in strings:''
; 7-8 : Would you like to help improve Firefox by automatically reporting memory usage, performance, and responsiveness to Mozilla? ([https://hg.mozilla.org/mozilla-central/rev/2efc1f37ce92#l3.16 link to patch])
; 9+ : Will you help improve Firefox by sending anonymous information about performance, hardware characteristics, feature usage, and browser customizations to Mozilla? ([https://hg.mozilla.org/mozilla-central/rev/cf6245609f48#l2.16 link to patch])

== Measurements flagged for Review ==

Data that's being collected potentially has privacy implications and ''must'' undergo a quick risk analysis. These measurements are listed below including any outcomes from the risk analysis.

[[Privacy/Reviews/Telemetry/Measurement Template|Get the lightweight-review template here]]

=== Undeployed (Not yet in Nightly/Aurora/Beta/Release) ===
{| class="wikitable sortable"
|-
! Not yet deployed Measurement
! Review Status
! Data Format Sample
! Notes
|-
| Layers backend
| {{resolved|in bug}}
| ("Direct3D 9" "Direct3D 10" "OpenGL" "Basic")
| {{bug|721785}}
|-
| Add telemetry for startup crash detection
| {{resolved|covered by opt-in}}
|
| {{bug|723802}}
|-
| [[Privacy/Reviews/Telemetry/SSL_Certificates_And_Errors|SSL Certificates and Errors]]
| {{#lst:Privacy/Reviews/Telemetry/SSL_Certificates_And_Errors|state}}
|
| {{bug|707275}} - not yet landed
|-
| [[Privacy/Reviews/Telemetry/Encountered Plugin Types|Encountered Plugin Types]]
| {{#lst:Privacy/Reviews/Telemetry/Encountered Plugin Types|state}}
|
| not yet landed
|-
| [[Privacy/Reviews/Telemetry/Profile Age|Profile Age]]
| {{#lst:Privacy/Reviews/Telemetry/Profile Age|state}}
|
| not yet landed
|-
| [[Privacy/Reviews/Telemetry/Default Browser Status|Default Browser Status]]
| {{#lst:Privacy/Reviews/Telemetry/Default Browser Status|state}}
|
| {{bug|679938}} - not yet landed
|-
| Mutation Event Listener Count
| {{resolved|not needed}}
| two counters
| {{bug|694033}} - window instance count and portion with MELs
|-
| Image decode count (# of encoded images per tab)
| {{resolved|}}
|
| {{bug|684091}}
|-
| createTopLevelWindow - timing
| {{resolved|not needed}}
|
| {{bug|686435}}
|-
| cpuid Data - (list of capabilities)
| {{resolved|in bug}}
|
| {{bug|684038}}
|-
| screen and window sizes
| {{resolved|in bug}}
|
| {{bug|683071}} (no patch yet)
|-
| slow prepared statements (sqlite)
| {{resolved|in bug}}
| SQL prepared statements (without user data, [https://bug699051.bugzilla.mozilla.org/attachment.cgi?id=576021 just the structure])
| {{bug|699051}}
|}

 

=== Deployed (In Nightly/Aurora/Beta/Release) ===

{| class="wikitable sortable"
|-
! Deployed Measurement
! Data format/sample
! Review Status
! Train/Release
! Notes
|-
| Character Encoding menu used
| flag
|
| 22
| {{bug|840476}}
|-
| Character Encoding menu use situation
| enumeration of usage situations (labeled page, unlabeled page, local file or not, etc.)
|
| 22
| {{bug|840476}}
|-
| Multipart XHR Usage
| boolean
|{{resolved|will determine fate of feature}}
|
| {{bug|701361}} Measurement removed in train 22 along with the feature whose usage was measured.
|-
| gfx hardware info
| "adapterDescription":"", "adapterVendorID":"0x1002", "adapterDeviceID":"0x944a", "adapterRAM":"", "adapterDriver":"", "adapterDriverVersion":"", "adapterDriverDate":""
| {{resolved|needed for gfx regressions}}
| 12 ([https://hg.mozilla.org/integration/mozilla-inbound/rev/e29b78989aeb patch])
| {{bug|706340}}
|-
| info.reason
| "idle-daily"
| {{resolved|not needed}}
| 7
| It's always the same string
|-
| info.OS
| "Darwin"
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| Short string (in UA)
|-
| info.appID
| GUID identifier
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| -
|-
| info.locale
| application locale (e.g., "en-US")
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/0ac4818e5b4b patch])
| -
|-
| info.appName
| "Firefox"
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| (in UA)
|-
| info.appVersion
| "7.0"
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| (in UA)
|-
| info.appBuildID
| "20110624030724"
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| Identifies date/time of build
|-
| info.platformBuildID
| "20110624030724"
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| ''same as appBuildID''
|-
| info.cpucount
| "2"
| {{resolved|not needed}}
| 7
| number of cores, etc.
|-
| info.memsize
| "2922"
| {{resolved|not needed}}
| 7
| RAM in megabytes 
|-
| info.arch
| "x86-64"
| {{resolved|not needed}}
| 7
| cpu architecture
|-
| info.version
| "11.0.0"
| {{resolved|not needed}}
| 7
| os version (in UA)
|-
| info.device
| "N810"
| {{resolved|not needed}}
| 7
| present on mobile only
|-
| info.manufacturer
| "Nokia"
| {{resolved|not needed}}
| 7
| present on mobile only
|-
| info.hardware
| "smdkc210"
| {{resolved|not needed}}
| 7
| Android hardware description (mfr code-name)
|-
| info.persona
| "336461" (integer ID)
| {{resolved|opt-in adjusted for 9}}
| 9
| Present when a persona is enabled
|-
| info.addons
| name/GUID/version of installed addons
| {{resolved|opt-in adjusted for 9}}
| 9
| Always present
|-
| simpleMeasurements.uptime
| "22"
| {{resolved|not needed}}
| 7
| application uptime in minutes
|-
| simpleMeasurements.main
| "1000"
| {{resolved|not needed}}
| 7
| milliseconds from startup in main()
|-
| simpleMeasurements.firstPaint
| "2000"
| {{resolved|not needed}}
| 7
| milliseconds from startup to first paint
|-
| simpleMasurements.sessionRestored
| "3000"
| {{resolved|not needed}}
| 7
| milliseconds from startup to session restore
|-
| simpleMeasurements.js.e4x
| "0"
| {{resolved|opt-in adjusted for 9}}
| 8 ([http://hg.mozilla.org/mozilla-central/rev/ba19e1cd3f91 patch])
| number of e4x objects created since browser startup
|-
| simpleMeasurements.js.setProto
| "0"
| {{resolved|opt-in adjusted for 9}}
| 8 ([http://hg.mozilla.org/mozilla-central/rev/ba19e1cd3f91 patch])
| number of times the __proto__ property has been set
|-
| simpleMeasurements.js.customIter
| "0"
| {{resolved|opt-in adjusted for 9}}
| 8 ([http://hg.mozilla.org/mozilla-central/rev/ba19e1cd3f91 patch])
| number of times a custom __iterator__ was used
|}

[[Category:Privacy/Reviews|TelemetryMeasurements]]

Privacy/Reviews/Telemetry/Measurements

2013-02-28T08:53:44Z

Hsivonen: /* Deployed (In Nightly/Aurora/Beta/Release) */ Add character encoding menu probes

__NOTOC__
As [[Platform/Features/Telemetry|Telemetry]] matures and we add more types of data we want to measure, it is important to keep track of what we're gathering and how we're respecting users' privacy. This page lists all of the types of data collected and links to any risk analysis done for the specific measurements.

The current list of histograms collected is in [http://mxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/TelemetryHistograms.h toolkit/components/telemetry/TelemetryHistograms.h]

Instead of full reviews on each major type of measurement, a lightweight risk analysis should be performed to quickly document the question each measurement answers as well as actions taken to minimize privacy risks.

==Histograms==
Histograms that are collected by telemetry are listed in [http://mxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/TelemetryHistograms.h TelemetryHistograms.h], and ones that have review are also listed in the table below.

== Relevant Strings ==
Privacy Policy: [http://www.mozilla.com/en-US/legal/privacy/firefox.html#telemetry http://www.mozilla.com/en-US/legal/privacy/firefox.html#telemetry]

''Opt-in strings:''
; 7-8 : Would you like to help improve Firefox by automatically reporting memory usage, performance, and responsiveness to Mozilla? ([https://hg.mozilla.org/mozilla-central/rev/2efc1f37ce92#l3.16 link to patch])
; 9+ : Will you help improve Firefox by sending anonymous information about performance, hardware characteristics, feature usage, and browser customizations to Mozilla? ([https://hg.mozilla.org/mozilla-central/rev/cf6245609f48#l2.16 link to patch])

== Measurements flagged for Review ==

Data that's being collected potentially has privacy implications and ''must'' undergo a quick risk analysis. These measurements are listed below including any outcomes from the risk analysis.

[[Privacy/Reviews/Telemetry/Measurement Template|Get the lightweight-review template here]]

=== Undeployed (Not yet in Nightly/Aurora/Beta/Release) ===
{| class="wikitable sortable"
|-
! Not yet deployed Measurement
! Review Status
! Data Format Sample
! Notes
|-
| Layers backend
| {{resolved|in bug}}
| ("Direct3D 9" "Direct3D 10" "OpenGL" "Basic")
| {{bug|721785}}
|-
| Add telemetry for startup crash detection
| {{resolved|covered by opt-in}}
|
| {{bug|723802}}
|-
| [[Privacy/Reviews/Telemetry/SSL_Certificates_And_Errors|SSL Certificates and Errors]]
| {{#lst:Privacy/Reviews/Telemetry/SSL_Certificates_And_Errors|state}}
|
| {{bug|707275}} - not yet landed
|-
| [[Privacy/Reviews/Telemetry/Encountered Plugin Types|Encountered Plugin Types]]
| {{#lst:Privacy/Reviews/Telemetry/Encountered Plugin Types|state}}
|
| not yet landed
|-
| [[Privacy/Reviews/Telemetry/Profile Age|Profile Age]]
| {{#lst:Privacy/Reviews/Telemetry/Profile Age|state}}
|
| not yet landed
|-
| [[Privacy/Reviews/Telemetry/Default Browser Status|Default Browser Status]]
| {{#lst:Privacy/Reviews/Telemetry/Default Browser Status|state}}
|
| {{bug|679938}} - not yet landed
|-
| Mutation Event Listener Count
| {{resolved|not needed}}
| two counters
| {{bug|694033}} - window instance count and portion with MELs
|-
| Image decode count (# of encoded images per tab)
| {{resolved|}}
|
| {{bug|684091}}
|-
| createTopLevelWindow - timing
| {{resolved|not needed}}
|
| {{bug|686435}}
|-
| cpuid Data - (list of capabilities)
| {{resolved|in bug}}
|
| {{bug|684038}}
|-
| screen and window sizes
| {{resolved|in bug}}
|
| {{bug|683071}} (no patch yet)
|-
| slow prepared statements (sqlite)
| {{resolved|in bug}}
| SQL prepared statements (without user data, [https://bug699051.bugzilla.mozilla.org/attachment.cgi?id=576021 just the structure])
| {{bug|699051}}
|}

 

=== Deployed (In Nightly/Aurora/Beta/Release) ===

{| class="wikitable sortable"
|-
! Deployed Measurement
! Data format/sample
! Review Status
! Train/Release
! Notes
|-
| Character Encoding menu used
| flag
|
| 22
| {{bug|840476}}
|-
| Character Encoding menu use situation
| enumeration of usage situations (labeled page, unlabeled page, local file or not, etc.)
|
| 22
| {{bug|840476}}
|-
| Multipart XHR Usage
| boolean
|{{resolved|will determine fate of feature}}
|
| {{bug|701361}}
|-
| gfx hardware info
| "adapterDescription":"", "adapterVendorID":"0x1002", "adapterDeviceID":"0x944a", "adapterRAM":"", "adapterDriver":"", "adapterDriverVersion":"", "adapterDriverDate":""
| {{resolved|needed for gfx regressions}}
| 12 ([https://hg.mozilla.org/integration/mozilla-inbound/rev/e29b78989aeb patch])
| {{bug|706340}}
|-
| info.reason
| "idle-daily"
| {{resolved|not needed}}
| 7
| It's always the same string
|-
| info.OS
| "Darwin"
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| Short string (in UA)
|-
| info.appID
| GUID identifier
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| -
|-
| info.locale
| application locale (e.g., "en-US")
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/0ac4818e5b4b patch])
| -
|-
| info.appName
| "Firefox"
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| (in UA)
|-
| info.appVersion
| "7.0"
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| (in UA)
|-
| info.appBuildID
| "20110624030724"
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| Identifies date/time of build
|-
| info.platformBuildID
| "20110624030724"
| {{resolved|not needed}}
| 7 ([http://hg.mozilla.org/mozilla-central/rev/998d4edbf4b3 patch])
| ''same as appBuildID''
|-
| info.cpucount
| "2"
| {{resolved|not needed}}
| 7
| number of cores, etc.
|-
| info.memsize
| "2922"
| {{resolved|not needed}}
| 7
| RAM in megabytes 
|-
| info.arch
| "x86-64"
| {{resolved|not needed}}
| 7
| cpu architecture
|-
| info.version
| "11.0.0"
| {{resolved|not needed}}
| 7
| os version (in UA)
|-
| info.device
| "N810"
| {{resolved|not needed}}
| 7
| present on mobile only
|-
| info.manufacturer
| "Nokia"
| {{resolved|not needed}}
| 7
| present on mobile only
|-
| info.hardware
| "smdkc210"
| {{resolved|not needed}}
| 7
| Android hardware description (mfr code-name)
|-
| info.persona
| "336461" (integer ID)
| {{resolved|opt-in adjusted for 9}}
| 9
| Present when a persona is enabled
|-
| info.addons
| name/GUID/version of installed addons
| {{resolved|opt-in adjusted for 9}}
| 9
| Always present
|-
| simpleMeasurements.uptime
| "22"
| {{resolved|not needed}}
| 7
| application uptime in minutes
|-
| simpleMeasurements.main
| "1000"
| {{resolved|not needed}}
| 7
| milliseconds from startup in main()
|-
| simpleMeasurements.firstPaint
| "2000"
| {{resolved|not needed}}
| 7
| milliseconds from startup to first paint
|-
| simpleMasurements.sessionRestored
| "3000"
| {{resolved|not needed}}
| 7
| milliseconds from startup to session restore
|-
| simpleMeasurements.js.e4x
| "0"
| {{resolved|opt-in adjusted for 9}}
| 8 ([http://hg.mozilla.org/mozilla-central/rev/ba19e1cd3f91 patch])
| number of e4x objects created since browser startup
|-
| simpleMeasurements.js.setProto
| "0"
| {{resolved|opt-in adjusted for 9}}
| 8 ([http://hg.mozilla.org/mozilla-central/rev/ba19e1cd3f91 patch])
| number of times the __proto__ property has been set
|-
| simpleMeasurements.js.customIter
| "0"
| {{resolved|opt-in adjusted for 9}}
| 8 ([http://hg.mozilla.org/mozilla-central/rev/ba19e1cd3f91 patch])
| number of times a custom __iterator__ was used
|}

[[Category:Privacy/Reviews|TelemetryMeasurements]]

Platform/2012-12-11

2012-12-11T19:10:12Z

Hsivonen: /* Issues */ Prefixing from last week

[[Platform/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous week]] | [[Platform|index]] | [[Platform/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]

<div class="h-event vevent">
'''Platform Meeting Details'''
* Tuesday {{#time: Y-m-d | {{SUBPAGENAME}} }} - 11:00 am <abbr class="value" title="-0700">Pacific</abbr>
{{conf|95312}}
* [https://v.mozilla.com/flex.html?roomdirect.html&key=UK1zyrd7Vhym Warp Core Vidyo Room] / SFO-Boardroom
* join irc.mozilla.org [irc://irc.mozilla.org/planning #planning] for back channel
</div>

==Notices/Schedule==
{| class="wikitable"
|-
| <center><big>[https://bugzilla.mozilla.org/buglist.cgi?type0-7-0=notequals;value0-7-0=%2B;field0-3-0=cf_status_firefox19;type0-1-0=notequals;type0-5-0=notequals;value0-5-0=disabled;value0-4-0=verified;field0-1-0=cf_status_firefox19;field0-0-0=cf_tracking_firefox19;type0-4-0=notequals;columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate;field0-6-0=cf_status_firefox19;value0-3-0=unaffected;field0-7-0=cf_tracking_firefox18;query_format=advanced;value0-2-0=fixed;value0-6-0=verified%20disabled;value0-1-0=wontfix;type0-3-0=notequals;field0-2-0=cf_status_firefox19;field0-5-0=cf_status_firefox19;field0-4-0=cf_status_firefox19;type0-6-0=notequals;type0-0-0=equals;value0-0-0=%2B;type0-2-0=notequals;list_id=5004437 35 bugs]</big> ([http://mzl.la/VR8z0w 27])</center>
| <center><big>[https://bugzilla.mozilla.org/buglist.cgi?type0-1-0=notequals;type0-5-0=notequals;value0-5-0=disabled;value0-4-0=verified;list_id=4754086;field0-1-0=cf_status_firefox18;field0-0-0=cf_tracking_firefox18;value0-3-0=unaffected;value0-6-0=verified%20disabled;value0-1-0=wontfix;field0-5-0=cf_status_firefox18;type0-0-0=equals;value0-0-0=%2B;type0-2-0=notequals;field0-3-0=cf_status_firefox18;type0-4-0=notequals;columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate;field0-6-0=cf_status_firefox18;query_format=advanced;value0-2-0=fixed;type0-3-0=notequals;field0-2-0=cf_status_firefox18;field0-4-0=cf_status_firefox18;type0-6-0=notequals 64 bugs]</big> ([http://mzl.la/VR8tpM 42])</center>
|-
! scope="row" | Unresolved Aurora Trackers (non-security, not tracked for Beta)
! scope="row" | Unresolved Beta Trackers (non-security)
|}

* Firefox 18.0 beta 4 is going to build today. No more speculative fixes.

==Products/Projects==

===Firefox OS===

* Stability and performance improving (smoketests much better, dogfooding reporting that perf is improving)
* Convergence milestone 3 starts today: http://people.mozilla.com/~dietrich/basecamp/c3.html
* Overall tracking data: http://people.mozilla.com/~dietrich/basecamp/counts.html
* (catlee) stub b2g tests on panda boards are now online on cedar
** for more details please read http://armenzg.blogspot.ca/2012/12/b2g-test-jobs-running-on-panda-boards.html
** or watch them running in https://tbpl.mozilla.org/?tree=Cedar&jobname=b2g_panda%20cedar%20opt%20test%20gaia-ui-test

===Firefox Desktop===
;Social
* Multi-provider support landed on inbound last night. Keep an eye out for any related issues in tomorrow's Nightly. We're going to see what the feedback is like before considering an uplift to Aurora 19.
;Download Panel
* Much of the work is complete, still some polish bugs to sort out. Primary remaining blocker is the new library downloads view, the team is on it.
;Performance
* {{bug|760036}} bounced because of mobile issues (underlying bug seems to be {{bug|772672}}). We'll need a workaround for mobile if fixing that bug can't happen soon.
;Per-window private browsing
* {{bug|818732}} per-window private browsing is almost here. Please help us test this when it gets turned on (will be in a few days.)

===Firefox Mobile===
; Responsiveness and Usability
* {{bug|811825}} : Reflow on zoom should have no effect on constrained height frames.

; Stability Wins
*{{Bug|735399}} - Only do session restore after a crash
*{{Bug|816902}} - java.lang.NullPointerException: at org.mozilla.gecko.AllPagesTab.setSuggestionsEnabled(AllPagesTab.java)
*{{bug|812867}} - java.lang.IllegalArgumentException: width must be > 0 at android.graphics.Bitmap.checkWidthHeight(Bitmap.java)
* java.lang.NullPointerException: Layout parameters cannot be null at android.view.View.setLayoutParams(View.java)

; In Progress
* WebRTC
** https://webrtc-apps.etherpad.mozilla.org/4
** WebRTC bugs, code now all compiles and links.
** Some landed, reviews for the rest pending.
* Reflow on Zoom work is ongoing

===Metro [Weekly]===

; Elm to mc merge

* Working on test failures for non-Windows platforms related to the app/gre split {{bug|747347}}.
* New packager should be on elm this week, may land on mc soonish.
* 7 bugs blocking (+2) {{bug|metro-build}} w/work TBD
* 5 bugs blocking (+3) {{bug|elm-merge}} w/work TBD

; Rel-eng

* Planning to switch mc to the 8.0 sdk after the next merge on ~2013-01-06 {{bug|774910}}

; Front-end

* First round of Download Manager work landed.
* Simplified touch event handling landed, plus some follow-up work.
* In progress: top site thumbnails; progress indicators; lots of UI polish

===Stability Report [Weekly]===

* js::GCMarker::processMarkStackTop is a top signature everywhere, has {{bug|719114}}, {{bug|803018}}, and {{bug|817342}} filed, would really need some investigation to get progress. We know GC crashes are a hard case, but we can't just ignore 3-5% of our crashes forever.
* {{Bug|812319}} and {{bug|572011}} are crashes related with the fully-JS Yandex Bar add-on, so this (in and aorund Russia) popular extension probably triggers problem in our own code. We need investigation of those.
* {{Bug|799118}} and {{bug|790473}} are two more JS crashes that have been spiking on trunk and need investigation.

====Mobile====
[[File:CrashStats_2012-12-11.png]]

QA investigation help needed... Can any dev can give some ideas?:
* {{bug|780831}} (JB crash in dvm) is still the #1 issue on beta and rising on release, STR would be good, but we have progress on it now.
* {{bug|782223}} (JB crash in tegra libs, mostly Nexus 7) is high on beta as well, also needs STR.

* [https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/17.0/3/all 17.0 Release top crashes]
* [https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/18.0b1/3/all 18.0b1 Beta top crashes]
* [https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/19.0a2/3/all Aurora top crashes]
* [https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/20.0a1/3/all Nightly top crashes]

====B2G====
* {{bug|817946}} - We seem to corrupt memory somewhere, which leads to pretty useless stacks in crash reports
** any leads on this would be great
* {{bug|814078}} - Submitting all pending crashes - just landed on trunk, waiting for getting onto beta
* nhirata and marcia working on end to end crash reporting - they will have info by 12/14.

===Snappy [Weekly]===
* Dec 6 [[Performance/Snappy/2012-12-06|Snappy status]]

; Start-up & Shutdown
* BenWa blogged about [http://benoitgirard.wordpress.com/2012/12/05/analyzing-shutdown-performance/ Analyzing Shutdown Performance]

; Tab Strip
* Vlad measured significantly reduced FPS rates during Australis tab animations that is particularly noticeable on weak hardware. Details in {{bug|738491#c76}}. More investigation and recommendations for the implementers coming.

;Content
* Paulo removed downloads from the main thread ({{bug|789932}})
* Aaron is continuing to make progress on the plug-in hang UI. Patches now up bug 805591: r+ from bbondy, sent to bsmedberg to review plugin facing parts of the patch and to shorlander for ui-review.
* Ben Smedberg and Aaron Klotz are looking at detaching the input queue of the main Firefox thread from the plugin-container main thread (Win32). This would address a type of plug-in hang that falls outside the scope of our plug-in hang detection code. ({{bug|818059}})
* Progress on moving local storage off the main thread ({{bug|807021}}, {{bug|600307}})

===Games [1st Tuesday of Month]===

===Mobile Web Compat [2nd Tuesday of Month]===
;Recent updates
* [http://lawrencemandel.com/2012/11/09/mobile-web-compatibility-nov-9-2012-video-update-ua-detection-tools-phony-for-b2g/ Mobile Web Compatibility Nov 9, 2012 – Video update, UA detection tools, Phony for B2G?]
* Learn how to site test in this [https://air.mozilla.org/mobile-web-test-event/ Air Mozilla video from Jason Smith]
* Recent [[Compatibility/Mobile#Minutes_and_Progress_Reports|meeting minutes]]

;B2G
* Targeting UA overrides for top 100 sites in select locales, the first being Brazil ({{bug|819210}})
** QA is working though the first candidate list this week.
* Lawrence wrote a script to change the B2G UA for testing. See https://groups.google.com/d/msg/mozilla.dev.b2g/01Pqtkzsiv4/WIOYsKDriq4J
* Find a problem with an Everything.me app? File it under [https://bugzilla.mozilla.org/enter_bug.cgi?product=Boot2Gecko&component=Gaia::Everything.me Boot2Gecko::Gaia::Everything.me]
* Find a problem with a Marketplace app? File it under [https://bugzilla.mozilla.org/enter_bug.cgi?product=Tech%20Evangelism&component=Mobile&rep_platform=ARM&op_sys=Gonk%20%28Firefox%20OS%29 Tech Evangelism::Mobile]] and cc Lisa Brewster (app review manager)

;Broken site deep dive investigation
* Josh Matthews and John Schoenick completed a investigation into why a specific set of sites are broken on Gecko. The goal was to better understand which Webkit CSS and DOM properties are causing breakage. See John's summary in {{bug|811421#c8}}.

===Critsmash [3rd Tuesday of Month]===
* Great work from Ted (etc) getting auto exploit analysis landed.

===Memshrink [4th Tuesday of Month]===

==Engineering Metrics==

==Key Issues==
=== Actions Last Week ===
* Mossop to follow up to mailing list about super-review status, update doc and post link
** Followed up in newsgroup, decided that no change is needed to the policy but have emailed all module owners to draw their attention to it and ask they talk with their reviewers
** https://groups.google.com/d/msg/mozilla.dev.platform/fZV-DYnqQEc/L8cBWmARBo8J
* Alex to investigate raising visibility of key web compat changes (ie UA)
* Milan to assign https://bugzilla.mozilla.org/show_bug.cgi?id=805745
* Karl T. to look at https://bugzilla.mozilla.org/show_bug.cgi?id=815542
* Jet look into https://bugzilla.mozilla.org/show_bug.cgi?id=696640
* Naveed look into https://bugzilla.mozilla.org/show_bug.cgi?id=817342

=== Issues ===
* Win64 builds (bsmedberg)
* Future Issues - early discussion on dev-platform, monitoring for discussion if not resolved
** MOZ_MAKE_FLAGS removal
* Linux32 tests (catlee/joduinn)
* Not shipping new prefixed non-WebGL, non-WebRTC APIs on the release channel. (hsivonen)

=== Actions ===

==Roundtable==
* {{bug|770844}} : Consider putting indexedDB on the window object itself, not on Window.prototype

Platform

2011-11-22T19:04:24Z

Hsivonen: /* Meetings */ Updated the conf # to the one that's actually used these days

This wiki page is devoted to the planning, scheduling, and documenting of meetings, discussions, and status of the Mozilla platform teams.

=== Planning ===
* See [[Platform/Planning | The Platform Planning Page]] for notes on upcoming releases and planning events. (NOTE: this used to be the [[Platform/Post1.9Planning | Post1.9Planning Spreadsheets for all releases after 1.9.]]).
* See also [[Firefox/Namoroka#Firefox.next Platform Requirements]] and its talk page.
* See also the [[Platform/Wanted|Wanted]] page for a few items wanted by extension/application developers

=== Platform Team Goals ===
* [[Platform/2011-Q4-Goals | 2011 Q4 Goals]]
* [[Platform/2011-Q3-Goals | 2011 Q3 Goals]]
* [[Platform/2011-Q2-Goals | 2011 Q2 Goals]]
* [[Platform/2011-Q1-Goals | 2011 Q1 Goals]]
* [[Platform/2010-Q4-Goals | 2010 Q4 Goals]]
* [[Platform/2010-Q3-Goals | 2010 Q3 Goals]]
* [[Platform/2010-Q2-Goals | 2010 Q2 Goals]]
* [[Platform/2010-Q1-Goals | 2010 Q1 Goals]]
* [[Platform/2009-Q4-Goals | 2009 Q4 Goals]]
* [[Platform/2009-Q3-Goals | 2009 Q3 Goals]]
* [[Platform/2009-Q2-Goals | 2009 Q2 Goals]]
* [[Platform/2009-Q1-Goals | 2009 Q1 Goals]]
* [[Platform/2008-Q4-Goals | 2008 Q4 Goals]]
* [[Platform/2008-Q3-Goals | 2008 Q3 Goals]]
* [[Platform/2008-Q2-Goals | 2008 Q2 Goals]]
* [[Platform/2008-Q1-Goals | 2008 Q1 Goals]]
* [[Platform/2007-Q3-Goals | 2007 Q3 Goals]]
* [[Platform/2007-Q2-Goals | 2007 Q2 Goals]]

=== Meetings ===
A weekly meeting is held to discuss Firefox/Gecko development
Meeting Details:
* Tuesdays - 11:00am Pacific, 2:00pm Eastern, 18:00 UTC (summer)
* Warp Core & Warp Core Vidyo Room
* 650-903-0800 x92 Conf# 95312 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 95312 (US)
* join irc.mozilla.org #planning for back channel

Watch the mozilla.dev.planning forum ([https://lists.mozilla.org/listinfo/dev-planning mailing list] | [http://groups.google.com/group/mozilla.dev.planning mozilla.dev.planning Google Group]) for weekly agendas and dial in details.

== Meeting Notes ==
([[Platform/0-0-0|template]])
* [[Platform/2011-11-22|22-November-2011]]
* [[Platform/2011-11-15|15-November-2011]]
* [[Platform/2011-11-08|08-November-2011]]
* [[Platform/2011-11-01|01-November-2011]]
* [[Platform/2011-10-25|25-October-2011]]
* [[Platform/2011-10-18|18-October-2011]]
* [[Platform/2011-10-11|11-October-2011]]
* [[Platform/2011-10-04|04-October-2011]]
* [[Platform/2011-09-27|27-September-2011]]
* [[Platform/2011-09-20|20-September-2011]]
* [[Platform/2011-09-06|6-September-2011]]
* [[Platform/2011-08-30|30-August-2011]]
* [[Platform/2011-08-23|23-August-2011]]
* [[Platform/2011-08-16|16-August-2011]]
* [[Platform/2011-08-09|9-August-2011]]
* [[Platform/2011-08-02|2-August-2011]]
* [[Platform/2011-07-26|26-July-2011]]
* [[Platform/2011-07-19|19-July-2011]]
* [[Platform/2011-07-12|12-July-2011]]
* [[Platform/2011-07-05|05-July-2011]]
* [[Platform/2011-06-28|28-June-2011]]
* [[Platform/2011-06-21|21-June-2011]]
* [[Platform/2011-06-14|14-June-2011]]
* [[Platform/2011-06-07|07-June-2011]]
* [[Platform/2011-05-31|31-May-2011]]
* [[Platform/2011-05-24|24-May-2011]]
* [[Platform/2011-05-17|17-May-2011]]
* [[Platform/2011-05-10|10-May-2011]]
* [[Platform/2011-05-03|03-May-2011]]
* [[Platform/2011-04-26|26-Apr-2011]]
* [[Platform/2011-04-19|19-Apr-2011]]
* [[Platform/2011-04-12|12-Apr-2011]]
* [[Platform/2011-03-29|29-Mar-2011]]
* ''22-Mar-2011 meeting cancelled due to Firefox 4 release celebrations''
* [[Platform/2011-03-15|15-Mar-2011]]
* [[Platform/2011-03-08|08-Mar-2011]]
* [[Platform/2011-03-01|01-Mar-2011]]
* [[Platform/2011-02-22|22-Feb-2011]]
* [[Platform/2011-02-15|15-Feb-2011]]
* [[Platform/2011-02-08|08-Feb-2011]]
* [[Platform/2011-02-01|01-Feb-2011]]
* [[Platform/2011-01-25|25-Jan-2011]]
* [[Platform/2011-01-18|18-Jan-2011]]
* [[Platform/2011-01-11|11-Jan-2011]]
* [[Platform/2011-01-04|04-Jan-2011]]

{{hidden
|2010
|
* 28-Dec-2010
* [[Platform/2010-12-21|21-Dec-2010]]
* [[Platform/2010-12-14|14-Dec-2010]]
* [[Platform/2010-12-07|07-Dec-2010]]
* [[Platform/2010-11-30|30-Nov-2010]]
* [[Platform/2010-11-23|23-Nov-2010]]
* [[Platform/2010-11-16|16-Nov-2010]]
* [[Platform/2010-11-09|09-Nov-2010]]
* [[Platform/2010-11-02|02-Nov-2010]]
* [[Platform/2010-10-26|26-Oct-2010]]
* [[Platform/2010-10-19|19-Oct-2010]]
* [[Platform/2010-10-12|12-Oct-2010]]
* [[Platform/2010-10-05|05-Oct-2010]]
* [[Platform/2010-09-28|28-Sep-2010]]
* [[Platform/2010-09-21|21-Sep-2010]]
* [[Platform/2010-09-14|14-Sep-2010]]
* [[Platform/2010-09-07|07-Sep-2010]]
* [[Platform/2010-08-31|31-Aug-2010]]
* [[Platform/2010-08-24|24-Aug-2010]]
* [[Platform/2010-08-17|17-Aug-2010]]
* [[Platform/2010-08-10|10-Aug-2010]]
* [[Platform/2010-08-03|03-Aug-2010]]
* [[Platform/2010-07-27|27-Jul-2010]]
* [[Platform/2010-07-20|20-Jul-2010]]
* [[Platform/2010-07-13|13-Jul-2010]]
* ''06-Jul-2010 meeting cancelled due to Mozilla Summit''
* [[Platform/2010-06-29|29-Jun-2010]]
* [[Platform/2010-06-22|22-Jun-2010]]
* [[Platform/2010-06-15|15-Jun-2010]]
* [[Platform/2010-06-08|08-Jun-2010]]
* [[Platform/2010-06-01|01-Jun-2010]]
* [[Platform/2010-05-25|25-May-2010]]
* [[Platform/2010-05-18|18-May-2010]]
* [[Platform/2010-05-11|11-May-2010]]
* [[Platform/2010-05-04|04-May-2010]]
* [[Platform/2010-04-27|27-Apr-2010]]
* [[Platform/2010-04-20|20-Apr-2010]]
* [[Platform/2010-04-13|13-Apr-2010]]
* [[Platform/2010-04-06|06-Apr-2010]]
* [[Platform/2010-03-30|30-Mar-2010]]
* [[Platform/2010-03-23|23-Mar-2010]]
* [[Platform/2010-03-16|16-Mar-2010]]
* [[Platform/2010-03-09|09-Mar-2010]]
* [[Platform/2010-03-02|02-Mar-2010]]
* [[Platform/2010-02-23|23-Feb-2010]]
* [[Platform/2010-02-16|16-Feb-2010]]
* [[Platform/2010-02-09|09-Feb-2010]]
* [[Platform/2010-02-02|02-Feb-2010]]
* [[Platform/2010-01-26|26-Jan-2010]]
* [[Platform/2010-01-19|19-Jan-2010]]
* [[Platform/2010-01-12|12-Jan-2010]]
* [[Platform/2010-01-05|05-Jan-2010]]
|headerstyle=background:#dddddd
}}

{{hidden
|Pre-1.9.2/Firefox 3.6
|
* [[Platform/2009-12-22|22-Dec-2009]]
* [[Platform/2009-12-15|15-Dec-2009]]
* [[Platform/2009-12-01|01-Dec-2009]]
* [[Platform/2009-11-24|24-Nov-2009]]
* [[Platform/2009-11-17|17-Nov-2009]]
* [[Platform/2009-11-10|10-Nov-2009]]
* [[Platform/2009-11-03|03-Nov-2009]]
* [[Platform/2009-10-27|27-Oct-2009]]
* [[Platform/2009-10-20|20-Oct-2009]]
* [[Platform/2009-10-13|13-Oct-2009]]
* [[Platform/2009-10-06|06-Oct-2009]]
* [[Platform/2009-09-29|29-Sep-2009]]
* [[Platform/2009-09-22|22-Sep-2009]]
* [[Platform/2009-09-15|15-Sep-2009]]
* [[Platform/2009-09-08|08-Sep-2009]]
* [[Platform/2009-09-01|01-Sep-2009]]
* [[Platform/2009-08-25|25-Aug-2009]]
* [[Platform/2009-08-18|18-Aug-2009]]
* [[Platform/2009-08-11|11-Aug-2009]]
* [[Platform/2009-08-04|04-Aug-2009]]
* [[Platform/2009-07-28|28-Jul-2009]]
* [[Platform/2009-07-21|21-Jul-2009]]
* [[Platform/2009-07-14|14-Jul-2009]]
* [[Platform/2009-07-07|07-Jul-2009]]
* [[Platform/2009-06-30|30-Jun-2009]]
* [[Platform/2009-06-23|23-Jun-2009]]
* [[Platform/2009-06-16|16-Jun-2009]]
* [[Platform/2009-06-09|09-Jun-2009]]
* [[Platform/2009-06-02|02-Jun-2009]]
* [[Platform/2009-05-26|26-May-2009]]
* [[Platform/2009-05-19|19-May-2009]]
* [[Platform/2009-05-12|12-May-2009]]
* [[Platform/2009-05-05|05-May-2009]]
* [[Platform/2009-04-21|21-Apr-2009]]
* [[Platform/2009-04-14|14-Apr-2009]]
* [[Platform/2009-04-07|07-Apr-2009]]
* [[Platform/2009-03-31|31-Mar-2009]]
* [[Platform/2009-03-24|24-Mar-2009]]
* [[Platform/2009-03-17|17-Mar-2009]]
* [[Platform/2009-03-10|10-Mar-2009]]
* [[Platform/2009-03-03|03-Mar-2009]]
* [[Platform/2009-02-24|24-Feb-2009]]
* [[Platform/2009-02-17|17-Feb-2009]]
* [[Platform/2009-02-10|10-Feb-2009]]
* [[Platform/2009-02-03|03-Feb-2009]]
* [[Platform/2009-01-27|27-Jan-2009]]
* [[Platform/2009-01-20|20-Jan-2009]]
* [[Platform/2009-01-13|13-Jan-2009]]
* [[Platform/2009-01-06|06-Jan-2009]]
* 30-Dec-2008 - canceled
* [[Platform/2008-12-23|23-Dec-2008]]
* [[Platform/2008-12-16|16-Dec-2008]]
* [[Platform/2008-12-09|09-Dec-2008]]
* [[Platform/2008-12-02|02-Dec-2008]]
* [[Platform/2008-11-25|25-November-2008]]
* [[Platform/2008-11-18|18-November-2008]]
* [[Platform/2008-11-11|11-November-2008]]
* [[Platform/2008-11-04|04-November-2008]]
* [[Platform/2008-10-28|28-October-2008]]
* [[Platform/2008-10-21|21-October-2008]]
* [[Platform/2008-10-14|14-October-2008]]
* [[Platform/2008-10-07|7-October-2008]]
* [[Platform/2008-09-30|30-September-2008]]
* [[Platform/2008-09-23|23-September-2008]]
* [[Platform/2008-09-16|16-September-2008]]
* [[Platform/2008-09-09|09-September-2008]]
* [[Platform/2008-09-02|02-September-2008]]
* [[Platform/2008-08-27|27-August-2008]]
* [[Platform/2008-08-20|20-August-2008]]
* [[Platform/2008-08-13|13-August-2008]]
* [[Platform/2008-08-06|06-August-2008]]
* [[Platform/2008-07-23|23-July-2008]]
* [[Platform/2008-07-16|16-July-2008]]
* [[Platform/2008-07-09|09-July-2008]]
* [[Platform/2008-07-02|02-July-2008]]
|headerstyle=background:#dddddd
}}

== Mozilla Platform Functional Groups ==
Some teams have their own meetings during the week to discuss specific issues:
* [[Platform/Layout | Layout Team]]
* [[Platform/GFX | Graphics Team]]
* [[Platform/Mac | Mac Team]]
* [[Platform/DOM | DOM Team]]
* [[Platform/JS | JavaScript Team]]

=== All Platform pages ===
Visit [[Special:PrefixIndex/{{FULLPAGENAME}}/]] to see all subpages of "{{FULLPAGENAME}}" on {{SERVERNAME}}.

Changing the UA String

2011-11-10T18:21:41Z

Hsivonen: /* Against */ Add a problem about equally capable devices/systems getting different content

Web browsers send a User Agent string on each request, which identifies the software being used and often some features of the platform. From time to time, proposals are made to change the User Agent string sent by Mozilla browsers. MDN [https://developer.mozilla.org/en/Gecko_user_agent_string_reference records our current user agent string]. This page is an attempt to document the arguments for and against, to avoid needless repetition. (Although the arguments 'for' tend to vary from case to case more than the arguments 'against'.)

==Against==

===Promotes Bad Habits===

To some extent (the extent is a matter of debate), how detailed a User Agent string is affects how much User Agent sniffing websites do. User Agent sniffing is regarded as a bad thing for the web, and has bitten the Mozilla project multiple times. [http://badassjs.com/post/1217357060/hasjs Feature detection] is the recommended method of causing websites to vary based on UA characteristics.

===Fingerprinting===

The more variable parts there are in the User Agent string, the more bits there are with which to fingerprint the browser - which is a [http://panopticlick.eff.org/ privacy problem]. Mozilla has worked hard in the last 2 years to reduce the variability of the User Agent string to an absolute minimum.

===Once Added, Things Can't Be Removed===

Current User Agent strings contain a pile of cruft which is required for backwards-compatibility. The longer a piece is in there, the more frozen it becomes. The first release of Mozilla updated the Mozilla/ token from Mozilla/4.0 to Mozilla/5.0, but it's never been incremented since. There was a desire to remove the Gecko date because it increased the browser's fingerprint, but it could not be removed because too much broke - it had to be fixed to a particular date.

This means that the barrier to adding new parts should be high.

===Makes Users with UA Strings the Author Didn't Test Get Worse Content===

Every difference in the UA string between two Firefox instances is an opportunity for sites to intentionally or accidentally send different content to two Firefox instances. This means that two users with equally capable systems can get different content and one of the users gets a substantially worse experience. Typically, the worse experience is with a configuration that the Web author didn't test but had prejudices about (or just plain bug combined with lack of testing).

Also, this phenomenon makes it harder to debug problems related to sites, because the person reporting the problem and the person debugging the problem can get different content.

===Each Addition Bloats Every Request===

The User Agent string is sent on every request. Therefore, like any such header (e.g. also the Accept: header), size is very important. The total bandwidth used by HTTP requests across the internet every day is mind-boggling. Also, if the size of your initial request gets too large, it ends up being broken into two packets, with corresponding possible performance penalties.

==For==

===Feature Detection Only Goes So Far===

A site needs to know some browser capabilities when rendering the very first response and so, if they are to avoid an extra round-trip and page load, they need to be provided with the necessary information up front.

===The Web Is Just Broken===

If a class of sites have content suitable for Firefox but are not sending it to us due to UA issues, changing the UA fixes the problem - whether or not you think they should have done that in the first place, that's what they've done and we have to deal with it.

==Notes==

* One alternative to UA string changes is evangelism. Particularly if only a few widely-used libraries need to be changed, it may be possible to bend the web to our will. Mozilla has done this before around the time of the Netscape 6 and Mozilla 1.0 releases with a massive evangelism effort. We can do that again if we have a task to rally around.

* For the best chance of success, proposals for change should to be accompanied by documented evidence of the improvements they bring.

Firefox/Unsupported OSes

2011-11-10T12:25:35Z

Hsivonen: /* Mac OS X */ Typo

{{draft}}

If Firefox is no longer supported on your operating system, Mozilla offers the following advice:

==Windows==

If you're not sure, you can [http://windows.microsoft.com/en-US/windows7/help/which-version-of-the-windows-operating-system-am-i-running find out which version of Windows you are running].

* '''Windows 95/98''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].
* '''Windows ME''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].
* '''Windows 2000''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].
* '''Windows XP Service Pack 1/Service Pack 2''': Your OS is no longer supported by its manufacturer. You should upgrade to [http://support.microsoft.com/kb/322389 the latest Windows XP Service Pack] (Service Pack 3, at the time of writing).
* '''Windows Vista Service Pack 1''': Your OS is no longer supported by its manufacturer. You should upgrade to [http://windows.microsoft.com/en-US/windows-vista/Learn-how-to-install-Windows-Vista-Service-Pack-2-SP2 the latest Windows Vista Service Pack] (Service Pack 2, at the time of writing).

All versions of Windows newer than those listed here are supported. Please install and run the [http://www.mozilla.org/en-US/firefox/fx/ latest version of Firefox].

==Mac OS X==

* '''OS X 10.4 or 10.5 on PowerPC''': You should install [http://www.floodgap.com/software/tenfourfox/ TenFourFox]. However, note that TenFourFox is not an official Mozilla release and does not have all the functions of official Firefox. In particular, plugins are not supported.
* '''OS X 10.4 on Intel''': You should upgrade to a newer version of OS X. Until then, you can install [http://www.floodgap.com/software/tenfourfox/ TenFourFox] and run it under Rosetta (Apple's PowerPC to Intel binary translation layer). However, note that TenFourFox is not an official Mozilla release and does not have all the functions of official Firefox. In particular, plugins are not supported.
* '''OS X 10.3 or earlier''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].

All versions of Mac OS X newer than those listed here are supported. Please install and run the [http://www.mozilla.org/en-US/firefox/fx/ latest version of Firefox].

==Linux==

Linux vendors often provide their own versions of Firefox. If that is the case for you, please consult your vendor about support and upgrades. If you are using a version of Firefox downloaded from Mozilla, then your Linux distribution needs to have the capabilities [http://www.mozilla.org/en-US/firefox/system-requirements.html outlined here]. If it does not, you will need to upgrade to a newer version of Linux.

==OS Unsupported By Manufacturer==

If your operating system is linked to this section, then it is longer receiving security updates from the OS manufacturer. Therefore, connecting to the Internet using it (with any browser) puts your data and the Internet ecosystem at risk. It is not possible to make such systems secure. You should either:

* Stop connecting to the Internet using this machine; or
* Upgrade the machine to a supported and secure operating system; or
* Replace the machine with one running a supported and secure operating system.

If the machine is unable to support newer versions from your OS manufacturer, you may wish to consider installing a different operating system.

Firefox/Unsupported OSes

2011-11-10T12:24:25Z

Hsivonen: /* Mac OS X */ Tweak OS X 10.4 Intel advice

{{draft}}

If Firefox is no longer supported on your operating system, Mozilla offers the following advice:

==Windows==

If you're not sure, you can [http://windows.microsoft.com/en-US/windows7/help/which-version-of-the-windows-operating-system-am-i-running find out which version of Windows you are running].

* '''Windows 95/98''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].
* '''Windows ME''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].
* '''Windows 2000''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].
* '''Windows XP Service Pack 1/Service Pack 2''': Your OS is no longer supported by its manufacturer. You should upgrade to [http://support.microsoft.com/kb/322389 the latest Windows XP Service Pack] (Service Pack 3, at the time of writing).
* '''Windows Vista Service Pack 1''': Your OS is no longer supported by its manufacturer. You should upgrade to [http://windows.microsoft.com/en-US/windows-vista/Learn-how-to-install-Windows-Vista-Service-Pack-2-SP2 the latest Windows Vista Service Pack] (Service Pack 2, at the time of writing).

All versions of Windows newer than those listed here are supported. Please install and run the [http://www.mozilla.org/en-US/firefox/fx/ latest version of Firefox].

==Mac OS X==

* '''OS X 10.4 or 10.5 on PowerPC''': You should install [http://www.floodgap.com/software/tenfourfox/ TenFourFox]. However, note that TenFourFox is not an official Mozilla release and does not have all the functions of official Firefox. In particular, plugins are not supported.
* '''OS X 10.4 on Intel''': You should upgrade to a newer version of OS X. Until then, you can install [http://www.floodgap.com/software/tenfourfox/ TenFourFox] and run it in under Rosetta (Apple's PowerPC to Intel binary translation layer). However, note that TenFourFox is not an official Mozilla release and does not have all the functions of official Firefox. In particular, plugins are not supported.
* '''OS X 10.3 or earlier''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].

All versions of Mac OS X newer than those listed here are supported. Please install and run the [http://www.mozilla.org/en-US/firefox/fx/ latest version of Firefox].

==Linux==

Linux vendors often provide their own versions of Firefox. If that is the case for you, please consult your vendor about support and upgrades. If you are using a version of Firefox downloaded from Mozilla, then your Linux distribution needs to have the capabilities [http://www.mozilla.org/en-US/firefox/system-requirements.html outlined here]. If it does not, you will need to upgrade to a newer version of Linux.

==OS Unsupported By Manufacturer==

If your operating system is linked to this section, then it is longer receiving security updates from the OS manufacturer. Therefore, connecting to the Internet using it (with any browser) puts your data and the Internet ecosystem at risk. It is not possible to make such systems secure. You should either:

* Stop connecting to the Internet using this machine; or
* Upgrade the machine to a supported and secure operating system; or
* Replace the machine with one running a supported and secure operating system.

If the machine is unable to support newer versions from your OS manufacturer, you may wish to consider installing a different operating system.

Firefox/Unsupported OSes

2011-11-10T12:21:34Z

Hsivonen: /* Mac OS X */ Split advice for PPC and Intel

{{draft}}

If Firefox is no longer supported on your operating system, Mozilla offers the following advice:

==Windows==

If you're not sure, you can [http://windows.microsoft.com/en-US/windows7/help/which-version-of-the-windows-operating-system-am-i-running find out which version of Windows you are running].

* '''Windows 95/98''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].
* '''Windows ME''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].
* '''Windows 2000''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].
* '''Windows XP Service Pack 1/Service Pack 2''': Your OS is no longer supported by its manufacturer. You should upgrade to [http://support.microsoft.com/kb/322389 the latest Windows XP Service Pack] (Service Pack 3, at the time of writing).
* '''Windows Vista Service Pack 1''': Your OS is no longer supported by its manufacturer. You should upgrade to [http://windows.microsoft.com/en-US/windows-vista/Learn-how-to-install-Windows-Vista-Service-Pack-2-SP2 the latest Windows Vista Service Pack] (Service Pack 2, at the time of writing).

All versions of Windows newer than those listed here are supported. Please install and run the [http://www.mozilla.org/en-US/firefox/fx/ latest version of Firefox].

==Mac OS X==

* '''OS X 10.4 or 10.5 on PowerPC''': You should install [http://www.floodgap.com/software/tenfourfox/ TenFourFox]. However, note that TenFourFox is not an official Mozilla release and does not have all the functions of official Firefox. In particular, plugins are not supported.
* '''OS X 10.4 on Intel''': You should either upgrade to a newer version of OS X, or install [http://www.floodgap.com/software/tenfourfox/ TenFourFox]. However, note that TenFourFox is not an official Mozilla release and does not have all the functions of official Firefox. In particular, plugins are not supported.
* '''OS X 10.3 or earlier''': Your OS is no longer supported by its manufacturer. [[Firefox/Unsupported_OSes#OS_Unsupported_By_Manufacturer|Please follow these instructions]].

All versions of Mac OS X newer than those listed here are supported. Please install and run the [http://www.mozilla.org/en-US/firefox/fx/ latest version of Firefox].

==Linux==

Linux vendors often provide their own versions of Firefox. If that is the case for you, please consult your vendor about support and upgrades. If you are using a version of Firefox downloaded from Mozilla, then your Linux distribution needs to have the capabilities [http://www.mozilla.org/en-US/firefox/system-requirements.html outlined here]. If it does not, you will need to upgrade to a newer version of Linux.

==OS Unsupported By Manufacturer==

If your operating system is linked to this section, then it is longer receiving security updates from the OS manufacturer. Therefore, connecting to the Internet using it (with any browser) puts your data and the Internet ecosystem at risk. It is not possible to make such systems secure. You should either:

* Stop connecting to the Internet using this machine; or
* Upgrade the machine to a supported and secure operating system; or
* Replace the machine with one running a supported and secure operating system.

If the machine is unable to support newer versions from your OS manufacturer, you may wish to consider installing a different operating system.

Mobile/Platforms

2011-06-30T13:07:28Z

Hsivonen: /* Supported Platforms */ Remove outdated version numbers

== About Firefox for Mobile ==

[[Fennec|Firefox for Mobile]] built on the same engine as Firefox 4 Beta, with extensive changes to optimize performance and user experience on mobile devices.

Firefox for mobile is just like our desktop browser – secure, powerful and customizable. It’s packed with many of the same features, including the Awesome Bar, add-ons, Firefox Sync and Location-Aware Browsing. Available in more than 25 languages and counting, Firefox for mobile is the most personalized mobile Web browser in the world. Learn more at our [[Mobile|Mozilla Mobile]] page.

== Supported Platforms ==

;[[/Maemo|Maemo]]
:Firefox for Maemo is available to download and use for the Nokia N900. Install it by visiting [http://firefox.com/m firefox.com/m] on your mobile device.

;[[/Android|Android]]
:Firefox is available for Android 2.0 and higher. See the [https://wiki.mozilla.org/Mobile/Platforms/Android#System_Requirements Android System Requirements] to check whether your Android phone is compatible with Firefox.

;[https://www.mozilla.com/mobile/home/ '''Firefox Home for iPhone''']
:Firefox Home is a free application for the iPhone and iPod Touch. Firefox Home lets you access your Firefox desktop history, bookmarks and open tabs on your iPhone. [http://itunes.apple.com/us/app/firefox-home/id380366933?mt=8 Download it for free on iTunes].

;[http://www.mozilla.com/mobile/download/ Mobile Firefox for desktop computers]
:Developers can install mobile Firefox on Mac, Windows, or Linux PCs to test mobile web sites and add-ons. (The desktop versions are intended for development purposes only.)

== Other Platforms ==

;Windows Mobile
:'''[http://blog.pavlov.net/2010/03/22/stopping-development-for-windows-mobile/ Firefox has stopped development for Windows Mobile indefinitely.]''' Thank you to our contributors for their continued support and feedback. The last release for Windows Mobile was [http://www.mozilla.org/projects/fennec/1.1a1-wm/releasenotes/ 1.1 alpha 1] ([http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2010/03/2010-03-22-02-mobile-1.9.2/ download]). We have stopped developing for Microsoft's mobile platform because Windows Phone 7 no longer allows developers to build C++ applications like Firefox, and Microsoft's new policies [http://arstechnica.com/microsoft/news/2011/02/windows-phone-marketplace-bans-the-gpl-and-the-app-store-should-too.ars ban open-source software like Firefox] from the Windows Phone Marketplace.

;iPhone/iPad/iPod
:We have no plans to release the full Firefox browser for iOS. The iOS SDK agreement requires apps to use Apple's own JavaScript engine (or none at all, like Opera Mini which downloads pre-rendered pages from Opera's servers and cannot run JavaScript code in the client). Because of this, we have no supported way to distribute Firefox's rendering and JavaScript engine to iPhone users.
:However, you can download [[Firefox Home for iPhone]], an iOS app that uses [[Firefox Sync]] to deliver Firefox bookmarks, browsing history, and tabs to your iPhone or iPod Touch.

;Palm webOS
:We currently have no plans to develop Firefox for the Palm Pre/webOS platform, but there is an [http://www.fractalbrew.com/labs/prefox/ unofficial port by Dave Townsend].

;Blackberry
:Due to the Java-based development system and inability to build C/C++ apps, the full Firefox browser will not be available on the Blackberry OS. However, a [http://blog.mozilla.com/mobile/2010/09/28/firefox-home-looking-to-the-future/ future version of Firefox Home] may be available for Blackberry.

;Symbian
:We currently have no plans to develop a full Firefox browser for the Symbian platform. See [[Mobile/Symbian]] for notes from an inactive project to port Firefox to Symbian. However, a [http://blog.mozilla.com/mobile/2010/09/28/firefox-home-looking-to-the-future/ future version of Firefox Home] may be available for Symbian.

;Feature phones
:We’ve targeted our development for smartphones. Standard mobile or feature phones are not powerful enough to support a great Firefox user experience.

== Recommended Hardware ==

See [[Mobile/Devices]].

Platform/XML Rewrite

2011-04-27T15:01:43Z

Hsivonen: /* Non-Goals */

("I" in this page refers to hsivonen.)

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Get rid of content-initiated flushes
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from sinks
* Moving XUL/XBL1/SAX/RDF/XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

==XML Web content loading==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::parser::xml::Parser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::parser::xml::StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::parser::xml::TreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::parser::TreeOpExecutor)

===Character encodings===

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an API for plugging in support for other decoders. So why bother with putting bytes to UTF-16 conversion in mozilla::parser::xml::StreamParser outside expat?

Unfortunately, expat has an unconventional API for encoding pluggability. Instead of having an API where byte buffers go in and UTF-16 or UTF-8 buffers come out, expat has an API for loading conversion tables into expat in the format that expat wants. Our pre-existing decoders don't expose their internals in that format. Therefore, to be able to use our pre-existing converters, we can't let expat manage the conversion.

Encoding sniffing should be handled the [https://bugzilla.mozilla.org/attachment.cgi?id=524615&action=diff same way nsHtml5StreamParser handles it in the XML View Source mode]: mozilla::parser::xml::StreamParser itself should handle UTF-8 and UTF-16 BOM sniffing. If there's no BOM, an instance of expat itself should be used for extracting the encoding name from the XML declaration.

===Connecting handlers to expat===

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::parser::xml::TreeOpGenerator should know how to register itself as the handler of various expat callbacks. This way, we don't need a layer of virtual calls on right on top of expat's function pointer-based calls.

I think it would make sense to have a common superclass for classes that can handle expat callbacks, but instead of being anything like nsIXMLContentSink or nsIExpatSink, I think the only commonality the classes need to have is the ability to register themselves as expat callback handler. So the common superclass could look like this:

class mozilla::parser::xml::AExpatHandler {
virtual void RegisterCallbacksInto(XML_Parser aParser) = 0;
};

===Dealing with stream data off the main thread===

mozilla::parser::xml::StreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

===Dealing with entity references off the main thread===

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything.

===Lack of actual speculation===

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::parser::xml::StreamParser: mozilla::parser::xml::MainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

==Parsing XML that's not Web content-like==

We have various uses of expat that don't currently target nsXMLContentSink. XUL, XBL1, XSLT (transformation program compilation), RDF and SAX all have special sinks. It's probably not worthwhile to move these off the main thread or to otherwise make substantial changes here. I propose making these cases use mozilla::parser::xml::MainThreadStreamParser for feeding content to expat and to deCOMtaminate the special sinks so that they inherit from mozilla::parser::xml::AExpatHandler (presented above) and know how to set themselves directly as expat callback handlers.

==Fragment parsing==

On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths.

==XSLT and XHR==

The document that is given as input to an XSLT program and the document loaded via XHR are currently built by nsXMLContentSink. In the new world, they'd use the tree op mechanism instead like other things that currently use nsXMLContentSink.

==Showing a common interface to nsDocument==

nsIParser is pointlessly crufty and COMtaminated. There should be a new non-XPCOM abstract class that shows the commonality of XML and HTML parsing to nsDocument but no cruft. The new interface should look something like this:

class mozilla::parser::AParser {
virtual void setCharsetAndSource(nsACString aCharset, PRInt32 aSource) = 0;
virtual nsIStreamListener* GetStreamListener() = 0;
virtual void UnblockParser() = 0;
virtual void Start(nsIRequestObserver* aObserver) = 0; // Replaces Parse()
virtual void Terminate() = 0;
// possibly document.write and script execution stuff that'd be no-op in the XML case
};

Both mozilla::parser::xml::Parser and nsHtml5Parser (to be renamed mozilla::parser::html::Parser) would inherit from this abstract class.

Platform/XML Rewrite

2011-04-27T14:58:26Z

Hsivonen: /* Connecting handlers to expat */

("I" in this page refers to hsivonen.)

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Get rid of content-initiated flushes
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from application code
* Moving XUL/XBL1/SAX/RDF/XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

==XML Web content loading==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::parser::xml::Parser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::parser::xml::StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::parser::xml::TreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::parser::TreeOpExecutor)

===Character encodings===

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an API for plugging in support for other decoders. So why bother with putting bytes to UTF-16 conversion in mozilla::parser::xml::StreamParser outside expat?

Unfortunately, expat has an unconventional API for encoding pluggability. Instead of having an API where byte buffers go in and UTF-16 or UTF-8 buffers come out, expat has an API for loading conversion tables into expat in the format that expat wants. Our pre-existing decoders don't expose their internals in that format. Therefore, to be able to use our pre-existing converters, we can't let expat manage the conversion.

Encoding sniffing should be handled the [https://bugzilla.mozilla.org/attachment.cgi?id=524615&action=diff same way nsHtml5StreamParser handles it in the XML View Source mode]: mozilla::parser::xml::StreamParser itself should handle UTF-8 and UTF-16 BOM sniffing. If there's no BOM, an instance of expat itself should be used for extracting the encoding name from the XML declaration.

===Connecting handlers to expat===

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::parser::xml::TreeOpGenerator should know how to register itself as the handler of various expat callbacks. This way, we don't need a layer of virtual calls on right on top of expat's function pointer-based calls.

I think it would make sense to have a common superclass for classes that can handle expat callbacks, but instead of being anything like nsIXMLContentSink or nsIExpatSink, I think the only commonality the classes need to have is the ability to register themselves as expat callback handler. So the common superclass could look like this:

class mozilla::parser::xml::AExpatHandler {
virtual void RegisterCallbacksInto(XML_Parser aParser) = 0;
};

===Dealing with stream data off the main thread===

mozilla::parser::xml::StreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

===Dealing with entity references off the main thread===

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything.

===Lack of actual speculation===

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::parser::xml::StreamParser: mozilla::parser::xml::MainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

==Parsing XML that's not Web content-like==

We have various uses of expat that don't currently target nsXMLContentSink. XUL, XBL1, XSLT (transformation program compilation), RDF and SAX all have special sinks. It's probably not worthwhile to move these off the main thread or to otherwise make substantial changes here. I propose making these cases use mozilla::parser::xml::MainThreadStreamParser for feeding content to expat and to deCOMtaminate the special sinks so that they inherit from mozilla::parser::xml::AExpatHandler (presented above) and know how to set themselves directly as expat callback handlers.

==Fragment parsing==

On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths.

==XSLT and XHR==

The document that is given as input to an XSLT program and the document loaded via XHR are currently built by nsXMLContentSink. In the new world, they'd use the tree op mechanism instead like other things that currently use nsXMLContentSink.

==Showing a common interface to nsDocument==

nsIParser is pointlessly crufty and COMtaminated. There should be a new non-XPCOM abstract class that shows the commonality of XML and HTML parsing to nsDocument but no cruft. The new interface should look something like this:

class mozilla::parser::AParser {
virtual void setCharsetAndSource(nsACString aCharset, PRInt32 aSource) = 0;
virtual nsIStreamListener* GetStreamListener() = 0;
virtual void UnblockParser() = 0;
virtual void Start(nsIRequestObserver* aObserver) = 0; // Replaces Parse()
virtual void Terminate() = 0;
// possibly document.write and script execution stuff that'd be no-op in the XML case
};

Both mozilla::parser::xml::Parser and nsHtml5Parser (to be renamed mozilla::parser::html::Parser) would inherit from this abstract class.

Platform/XML Rewrite

2011-04-27T14:51:43Z

Hsivonen:

("I" in this page refers to hsivonen.)

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Get rid of content-initiated flushes
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from application code
* Moving XUL/XBL1/SAX/RDF/XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

==XML Web content loading==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::parser::xml::Parser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::parser::xml::StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::parser::xml::TreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::parser::TreeOpExecutor)

===Character encodings===

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an API for plugging in support for other decoders. So why bother with putting bytes to UTF-16 conversion in mozilla::parser::xml::StreamParser outside expat?

Unfortunately, expat has an unconventional API for encoding pluggability. Instead of having an API where byte buffers go in and UTF-16 or UTF-8 buffers come out, expat has an API for loading conversion tables into expat in the format that expat wants. Our pre-existing decoders don't expose their internals in that format. Therefore, to be able to use our pre-existing converters, we can't let expat manage the conversion.

Encoding sniffing should be handled the [https://bugzilla.mozilla.org/attachment.cgi?id=524615&action=diff same way nsHtml5StreamParser handles it in the XML View Source mode]: mozilla::parser::xml::StreamParser itself should handle UTF-8 and UTF-16 BOM sniffing. If there's no BOM, an instance of expat itself should be used for extracting the encoding name from the XML declaration.

===Connecting handlers to expat===

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::parser::xml::TreeOpGenerator should know how to register itself as the handler of various expat callbacks.

I think it would make sense to have a common superclass for classes that can handle expat callbacks, but instead of being anything like nsIXMLContentSink or nsIExpatSink, I think the only commonality the classes need to have is the ability to register themselves as expat callback handler. So the common superclass could look like this:

class mozilla::parser::xml::AExpatHandler {
virtual void RegisterCallbacksInto(XML_Parser aParser) = 0;
};

===Dealing with stream data off the main thread===

mozilla::parser::xml::StreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

===Dealing with entity references off the main thread===

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything.

===Lack of actual speculation===

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::parser::xml::StreamParser: mozilla::parser::xml::MainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

==Parsing XML that's not Web content-like==

We have various uses of expat that don't currently target nsXMLContentSink. XUL, XBL1, XSLT (transformation program compilation), RDF and SAX all have special sinks. It's probably not worthwhile to move these off the main thread or to otherwise make substantial changes here. I propose making these cases use mozilla::parser::xml::MainThreadStreamParser for feeding content to expat and to deCOMtaminate the special sinks so that they inherit from mozilla::parser::xml::AExpatHandler (presented above) and know how to set themselves directly as expat callback handlers.

==Fragment parsing==

On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths.

==XSLT and XHR==

The document that is given as input to an XSLT program and the document loaded via XHR are currently built by nsXMLContentSink. In the new world, they'd use the tree op mechanism instead like other things that currently use nsXMLContentSink.

==Showing a common interface to nsDocument==

nsIParser is pointlessly crufty and COMtaminated. There should be a new non-XPCOM abstract class that shows the commonality of XML and HTML parsing to nsDocument but no cruft. The new interface should look something like this:

class mozilla::parser::AParser {
virtual void setCharsetAndSource(nsACString aCharset, PRInt32 aSource) = 0;
virtual nsIStreamListener* GetStreamListener() = 0;
virtual void UnblockParser() = 0;
virtual void Start(nsIRequestObserver* aObserver) = 0; // Replaces Parse()
virtual void Terminate() = 0;
// possibly document.write and script execution stuff that'd be no-op in the XML case
};

Both mozilla::parser::xml::Parser and nsHtml5Parser (to be renamed mozilla::parser::html::Parser) would inherit from this abstract class.

Platform/XML Rewrite

2011-04-27T14:36:15Z

Hsivonen:

("I" in this page refers to hsivonen.)

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Get rid of content-initiated flushes
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from application code
* Moving XUL/XBL1/SAX/RDF/XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

==XML Web content loading==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::parser::xml::Parser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::parser::xml::StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::parser::xml::TreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::parser::TreeOpExecutor)

===Character encodings===

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an API for plugging in support for other decoders. So why bother with putting bytes to UTF-16 conversion in mozilla::parser::xml::StreamParser outside expat?

Unfortunately, expat has an unconventional API for encoding pluggability. Instead of having an API where byte buffers go in and UTF-16 or UTF-8 buffers come out, expat has an API for loading conversion tables into expat in the format that expat wants. Our pre-existing decoders don't expose their internals in that format. Therefore, to be able to use our pre-existing converters, we can't let expat manage the conversion.

Encoding sniffing should be handled the [https://bugzilla.mozilla.org/attachment.cgi?id=524615&action=diff same way nsHtml5StreamParser handles it in the XML View Source mode]: mozilla::parser::xml::StreamParser itself should handle UTF-8 and UTF-16 BOM sniffing. If there's no BOM, an instance of expat itself should be used for extracting the encoding name from the XML declaration.

===Connecting handlers to expat===

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::parser::xml::TreeOpGenerator should know how to register itself as the handler of various expat callbacks.

I think it would make sense to have a common superclass for classes that can handle expat callbacks, but instead of being anything like nsIXMLContentSink or nsIExpatSink, I think the only commonality the classes need to have is the ability to register themselves as expat callback handler. So the common superclass could look like this:

class mozilla::parser::xml::AExpatHandler {
virtual void RegisterCallbacksInto(XML_Parser aParser) = 0;
};

===Dealing with stream data off the main thread===

mozilla::parser::xml::StreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

===Dealing with entity references off the main thread===

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything.

===Lack of actual speculation===

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::parser::xml::StreamParser: mozilla::parser::xml::MainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

==Parsing XML that's not Web content-like==

We have various uses of expat that don't currently target nsXMLContentSink. XUL, XBL1, XSLT (transformation program compilation), RDF and SAX all have special sinks. It's probably not worthwhile to move these off the main thread or to otherwise make substantial changes here. I propose making these cases use mozilla::parser::xml::MainThreadStreamParser for feeding content to expat and to deCOMtaminate the special sinks so that they inherit from mozilla::parser::xml::AExpatHandler (presented above) and know how to set themselves directly as expat callback handlers.

==Fragment parsing==

On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths.

==XSLT and XHR==

The document that is given as input to an XSLT program and the document loaded via XHR are currently built by nsXMLContentSink. In the new world, they'd use the tree op mechanism instead like other things that currently use nsXMLContentSink.

Platform/XML Rewrite

2011-04-27T14:34:48Z

Hsivonen:

("I" in this page refers to hsivonen.)

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Get rid of content-initiated flushes
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from application code
* Moving XUL/XBL1/SAX/RDF/XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

==XML Web content loading==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::parser::xml::Parser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::parser::xml::StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::parser::xml::TreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::parser::TreeOpExecutor)

===Details about Web content loading===

====Character encodings====

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an API for plugging in support for other decoders. So why bother with putting bytes to UTF-16 conversion in mozilla::parser::xml::StreamParser outside expat?

Unfortunately, expat has an unconventional API for encoding pluggability. Instead of having an API where byte buffers go in and UTF-16 or UTF-8 buffers come out, expat has an API for loading conversion tables into expat in the format that expat wants. Our pre-existing decoders don't expose their internals in that format. Therefore, to be able to use our pre-existing converters, we can't let expat manage the conversion.

Encoding sniffing should be handled the [https://bugzilla.mozilla.org/attachment.cgi?id=524615&action=diff same way nsHtml5StreamParser handles it in the XML View Source mode]: mozilla::parser::xml::StreamParser itself should handle UTF-8 and UTF-16 BOM sniffing. If there's no BOM, an instance of expat itself should be used for extracting the encoding name from the XML declaration.

====Connecting handlers to expat====

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::parser::xml::TreeOpGenerator should know how to register itself as the handler of various expat callbacks.

I think it would make sense to have a common superclass for classes that can handle expat callbacks, but instead of being anything like nsIXMLContentSink or nsIExpatSink, I think the only commonality the classes need to have is the ability to register themselves as expat callback handler. So the common superclass could look like this:

class mozilla::parser::xml::AExpatHandler {
virtual void RegisterCallbacksInto(XML_Parser aParser) = 0;
};

====Dealing with stream data off the main thread====

mozilla::parser::xml::StreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

====Dealing with entity references off the main thread====

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything.

====Lack of actual speculation====

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::parser::xml::StreamParser: mozilla::parser::xml::MainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

==Parsing XML that's not Web content-like==

We have various uses of expat that don't currently target nsXMLContentSink. XUL, XBL1, XSLT (transformation program compilation), RDF and SAX all have special sinks. It's probably not worthwhile to move these off the main thread or to otherwise make substantial changes here. I propose making these cases use mozilla::parser::xml::MainThreadStreamParser for feeding content to expat and to deCOMtaminate the special sinks so that they inherit from mozilla::parser::xml::AExpatHandler (presented above) and know how to set themselves directly as expat callback handlers.

==Fragment parsing==

On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths.

==XSLT and XHR==

The document that is given as input to an XSLT program and the document loaded via XHR are currently built by nsXMLContentSink. In the new world, they'd use the tree op mechanism instead like other things that currently use nsXMLContentSink.

Platform/XML Rewrite

2011-04-27T14:33:53Z

Hsivonen: /* Fragment parsing */

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Get rid of content-initiated flushes
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from application code
* Moving XUL/XBL1/SAX/RDF/XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

==XML Web content loading==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::parser::xml::Parser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::parser::xml::StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::parser::xml::TreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::parser::TreeOpExecutor)

===Details about Web content loading===

====Character encodings====

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an API for plugging in support for other decoders. So why bother with putting bytes to UTF-16 conversion in mozilla::parser::xml::StreamParser outside expat?

Unfortunately, expat has an unconventional API for encoding pluggability. Instead of having an API where byte buffers go in and UTF-16 or UTF-8 buffers come out, expat has an API for loading conversion tables into expat in the format that expat wants. Our pre-existing decoders don't expose their internals in that format. Therefore, to be able to use our pre-existing converters, we can't let expat manage the conversion.

Encoding sniffing should be handled the [https://bugzilla.mozilla.org/attachment.cgi?id=524615&action=diff same way nsHtml5StreamParser handles it in the XML View Source mode]: mozilla::parser::xml::StreamParser itself should handle UTF-8 and UTF-16 BOM sniffing. If there's no BOM, an instance of expat itself should be used for extracting the encoding name from the XML declaration.

====Connecting handlers to expat====

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::parser::xml::TreeOpGenerator should know how to register itself as the handler of various expat callbacks.

I think it would make sense to have a common superclass for classes that can handle expat callbacks, but instead of being anything like nsIXMLContentSink or nsIExpatSink, I think the only commonality the classes need to have is the ability to register themselves as expat callback handler. So the common superclass could look like this:

class mozilla::parser::xml::AExpatHandler {
virtual void RegisterCallbacksInto(XML_Parser aParser) = 0;
};

====Dealing with stream data off the main thread====

mozilla::parser::xml::StreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

====Dealing with entity references off the main thread====

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything.

====Lack of actual speculation====

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::parser::xml::StreamParser: mozilla::parser::xml::MainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

==Parsing XML that's not Web content-like==

We have various uses of expat that don't currently target nsXMLContentSink. XUL, XBL1, XSLT (transformation program compilation), RDF and SAX all have special sinks. It's probably not worthwhile to move these off the main thread or to otherwise make substantial changes here. I propose making these cases use mozilla::parser::xml::MainThreadStreamParser for feeding content to expat and to deCOMtaminate the special sinks so that they inherit from mozilla::parser::xml::AExpatHandler (presented above) and know how to set themselves directly as expat callback handlers.

==Fragment parsing==

On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths.

==XSLT and XHR==

The document that is given as input to an XSLT program and the document loaded via XHR are currently built by nsXMLContentSink. In the new world, they'd use the tree op mechanism instead like other things that currently use nsXMLContentSink.

Platform/XML Rewrite

2011-04-27T14:31:58Z

Hsivonen: /* Basics for Web content loading on the XML side */

Platform/XML Rewrite

2011-04-27T14:31:03Z

Hsivonen:

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Get rid of content-initiated flushes
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from application code
* Moving XUL/XBL1/SAX/RDF/XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

==Basics for Web content loading on the XML side==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::parser::xml::Parser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::parser::xml::StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::parser::xml::TreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::parser::TreeOpExecutor)

===Details about Web content loading===

====Character encodings====

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an API for plugging in support for other decoders. So why bother with putting bytes to UTF-16 conversion in mozilla::parser::xml::StreamParser outside expat?

Unfortunately, expat has an unconventional API for encoding pluggability. Instead of having an API where byte buffers go in and UTF-16 or UTF-8 buffers come out, expat has an API for loading conversion tables into expat in the format that expat wants. Our pre-existing decoders don't expose their internals in that format. Therefore, to be able to use our pre-existing converters, we can't let expat manage the conversion.

Encoding sniffing should be handled the [https://bugzilla.mozilla.org/attachment.cgi?id=524615&action=diff same way nsHtml5StreamParser handles it in the XML View Source mode]: mozilla::parser::xml::StreamParser itself should handle UTF-8 and UTF-16 BOM sniffing. If there's no BOM, an instance of expat itself should be used for extracting the encoding name from the XML declaration.

====Connecting handlers to expat====

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::parser::xml::TreeOpGenerator should know how to register itself as the handler of various expat callbacks.

I think it would make sense to have a common superclass for classes that can handle expat callbacks, but instead of being anything like nsIXMLContentSink or nsIExpatSink, I think the only commonality the classes need to have is the ability to register themselves as expat callback handler. So the common superclass could look like this:

class mozilla::parser::xml::AExpatHandler {
virtual void RegisterCallbacksInto(XML_Parser aParser) = 0;
};

====Dealing with stream data off the main thread====

mozilla::parser::xml::StreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

====Dealing with entity references off the main thread====

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything.

====Lack of actual speculation====

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::parser::xml::StreamParser: mozilla::parser::xml::MainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

==Parsing XML that's not Web content-like==

We have various uses of expat that don't currently target nsXMLContentSink. XUL, XBL1, XSLT (transformation program compilation), RDF and SAX all have special sinks. It's probably not worthwhile to move these off the main thread or to otherwise make substantial changes here. I propose making these cases use mozilla::parser::xml::MainThreadStreamParser for feeding content to expat and to deCOMtaminate the special sinks so that they inherit from mozilla::parser::xml::AExpatHandler (presented above) and know how to set themselves directly as expat callback handlers.

==Fragment parsing==

On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths.

Platform/XML Rewrite

2011-04-27T14:22:26Z

Hsivonen: /* Parsing chrome: content */

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Get rid of content-initiated flushes
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from application code
* Moving XUL/XBL1/SAX/RDF/XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

The parser object also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser.

==Basics for Web content loading on the XML side==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::parser::xml::Parser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::parser::xml::StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::parser::xml::TreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::parser::TreeOpExecutor)

===Details about Web content loading===

====Character encodings====

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an API for plugging in support for other decoders. So why bother with putting bytes to UTF-16 conversion in mozilla::parser::xml::StreamParser outside expat?

Unfortunately, expat has an unconventional API for encoding pluggability. Instead of having an API where byte buffers go in and UTF-16 or UTF-8 buffers come out, expat has an API for loading conversion tables into expat in the format that expat wants. Our pre-existing decoders don't expose their internals in that format. Therefore, to be able to use our pre-existing converters, we can't let expat manage the conversion.

Encoding sniffing should be handled the [https://bugzilla.mozilla.org/attachment.cgi?id=524615&action=diff same way nsHtml5StreamParser handles it in the XML View Source mode]: mozilla::parser::xml::StreamParser itself should handle UTF-8 and UTF-16 BOM sniffing. If there's no BOM, an instance of expat itself should be used for extracting the encoding name from the XML declaration.

====Connecting handlers to expat====

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::parser::xml::TreeOpGenerator should know how to register itself as the handler of various expat callbacks.

I think it would make sense to have a common superclass for classes that can handle expat callbacks, but instead of being anything like nsIXMLContentSink or nsIExpatSink, I think the only commonality the classes need to have is the ability to register themselves as expat callback handler. So the common superclass could look like this:

class mozilla::parser::xml::AExpatHandler {
virtual void RegisterCallbacksInto(XML_Parser aParser) = 0;
};

====Dealing with stream data off the main thread====

mozilla::parser::xml::StreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

====Dealing with entity references off the main thread====

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything.

====Lack of actual speculation====

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: XML==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::parser::xml::StreamParser: mozilla::parser::xml::MainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

Platform/XML Rewrite

2011-04-27T14:21:59Z

Hsivonen: content: on the main thread

==Goals==

* Get rid of nsParser
* Get rid of nsScanner
* Get rid of nsIContentSink and related nsI stuff
* Get rid of nsIParser
* Get rid of content-initiated flushes
* Move Web content XML parsing off the main thread
* For Web content, reuse code from the HTML side
* Less COMtamination

==Non-Goals==

* Replacing expat
* Hiding expat from application code
* Moving XUL/XBL1/SAX/RDF/XSLT off the main thread

==Background observations==

The HTML5 parser has a design that works. When document.write handling complexity is not considered, the HTML5 parser has these major parts:
* A parser object (nsHtml5Parser) that nsDocument sees and that holds the rest together.
* An IO driver (nsHtml5StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to the portable parser core.
* The portable parser core (nsHtml5Tokenizer and nsHtml5TreeBuilder).
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement)
* An executor for the tree ops (nsHtml5TreeOpExecutor)

The parser object also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser.

==Basics for Web content loading on the XML side==

I propose making the XML Web content load path have the same structure as the HTML loads path (with document.write simplified out). That is, it would have these major parts:
* A parser object (mozilla::parser::xml::Parser) that nsDocument sees and that holds the rest together.
* An IO driver (mozilla::parser::xml::StreamParser) that can receive bytes from a network stream, manages the character encoding conversion and pushes UTF-16 code units to expat.
* expat (portable parser core)
* An object that implements handler callback for expat and produces tree ops. (mozilla::parser::xml::TreeOpGenerator)
* The same executor for the tree ops an on the HTML side (nsHtml5TreeOpExecutor, eventually to be named mozilla::parser::TreeOpExecutor)

===Details about Web content loading===

====Character encodings====

expat has built-in capability to decode US-ASCII, ISO-8859-1, UTF-8 and UTF-16 and has an API for plugging in support for other decoders. So why bother with putting bytes to UTF-16 conversion in mozilla::parser::xml::StreamParser outside expat?

Unfortunately, expat has an unconventional API for encoding pluggability. Instead of having an API where byte buffers go in and UTF-16 or UTF-8 buffers come out, expat has an API for loading conversion tables into expat in the format that expat wants. Our pre-existing decoders don't expose their internals in that format. Therefore, to be able to use our pre-existing converters, we can't let expat manage the conversion.

Encoding sniffing should be handled the [https://bugzilla.mozilla.org/attachment.cgi?id=524615&action=diff same way nsHtml5StreamParser handles it in the XML View Source mode]: mozilla::parser::xml::StreamParser itself should handle UTF-8 and UTF-16 BOM sniffing. If there's no BOM, an instance of expat itself should be used for extracting the encoding name from the XML declaration.

====Connecting handlers to expat====

Looking at the existing sinks, it looks like there's no real value in having an abstraction between expat and code that does the actual work in response to expat's callbacks. If we switched away from expat today, we'd have to change the current abstraction layer anyway. That is, I think it doesn't make sense to have a single class (like the old nsExpatDriver) that provides a set of expat callbacks and then provides another abstraction for concrete handler classes that do the real work. I propose we make the concrete handler classes set themselves as expat callbacks directly. That is, mozilla::parser::xml::TreeOpGenerator should know how to register itself as the handler of various expat callbacks.

I think it would make sense to have a common superclass for classes that can handle expat callbacks, but instead of being anything like nsIXMLContentSink or nsIExpatSink, I think the only commonality the classes need to have is the ability to register themselves as expat callback handler. So the common superclass could look like this:

class mozilla::parser::xml::AExpatHandler {
virtual void RegisterCallbacksInto(XML_Parser aParser) = 0;
};

====Dealing with stream data off the main thread====

mozilla::parser::xml::StreamParser should implement nsIStreamListener on the main thread and copy data over to the parser thread the way nsHtml5StreamParser does.

====Dealing with entity references off the main thread====

Currently, we map a small set of magic public ids to a DTD file that we actually feed to expat so that it gets parsed every time the user loads a document that references one of the magic public ids, such as the public ids for the XHTML 1.0 DTDs. This way, entities defined in the XHTML 1.0 DTDs are available to documents.

Since our IO APIs are meant to be called on the main thread, starting IO for the local DTD file from the parser thread is not good. And in any case, it's rather silly to parse an actual file when we know in advance what the file will contain.

Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything.

====Lack of actual speculation====

In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet.

==Parsing chrome: content==

Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::parser::xml::StreamParser: mozilla::parser::xml::MainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass.

Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread.

Platform/XML Rewrite

2011-04-27T14:00:02Z

Hsivonen: /* Details about Web content loading */

Platform/XML Rewrite

2011-04-27T13:34:05Z

Hsivonen: /* Connecting handlers to expat */

Platform/XML Rewrite

2011-04-27T13:24:47Z

Hsivonen: /* Details about Web content loading */

Platform/XML Rewrite

2011-04-27T13:20:56Z

Hsivonen: Typo

Platform/XML Rewrite

2011-04-27T13:20:25Z

Hsivonen: More plan

Platform/XML Rewrite

2011-04-27T12:52:29Z

Hsivonen: Start a plan

Platform/HTML5 sanitizer

2011-01-20T12:15:05Z

Hsivonen: /* Gecko Requirements */ Use one element whitelist instead of 3

==Gecko Requirements==

* Allow a setting for enabling styles.
* Allow a setting for enabling comments. See {{bug|572642}}
** Or always enable comments? (What about "--" in comments?)
* <s>Have three element white lists: HTML, SVG and MathML.</s>
** This turns out to lead to a lot of complexity without clear benefit.
* Have three attribute white lists: HTML, SVG and MathML. The attributes don't depend on the element they are on beyond the element namespace.
** XXX: Figure out what the requirements are for attributes starting with data- or _.
* Have three lists of attributes that take URLs. Drop the attributes when they have prohibited URLs (after trimming whitespace from the value).
** Resolve relative URLs into absolute ones using a per fragment base URL. (Is this correct for Gecko reqs? Current code uses the node's base URI. Is that right?)
** However, allow any URL in the src attribute on the img element, because imgs are safe. {{bug|572637}}
* Have a list of SVG attributes that take different-document references.
* Have a list of SVG attributes that are allowed to have same-document references only.
* If styles are allowed, sanitize style attribute values. If styles aren't allowed, drop the style attribute.
* Always drop script and title elements and their contents.
* If styles are disabled, drop style elements and their contents.
* If styles are enabled, sanitize the content of style elements.
* Add the controls attribute to the video and audio elements (if it isn't there already).

==Open Questions==

* Can stylistic SVG attributes have values that need to be sanitized?
* Should Semantic MathML be on the white list for clipboard round-tripping? (Mainly a footprint issue.)
* Is it dangerous for SVG fragment id references to be able to refer to an id in the document the untrusted fragment gets inserted into?
* What to do about HTML5 microdata?

==Non-Gecko Requirements==

These are features for the HTML5 parser when it is used outside Gecko.

* Allow form-related elements to be toggled on and off in the white list.
* Allow using the sanitizer in non-fragment mode (in which case, the title element should be allowed).
** Are there compelling use cases for non-fragment mode sanitization?
* Have a configurable white list of permitted URL schemes in attributes that take URLs.

Platform/HTML5 sanitizer

2011-01-12T13:26:26Z

Hsivonen: Microdata

==Gecko Requirements==

* Allow a setting for enabling styles.
* Allow a setting for enabling comments. See {{bug|572642}}
** Or always enable comments? (What about "--" in comments?)
* Have three element white lists: HTML, SVG and MathML.
* Have three attribute white lists: HTML, SVG and MathML. The attributes don't depend on the element they are on beyond the element namespace.
** XXX: Figure out what the requirements are for attributes starting with data- or _.
* Have three lists of attributes that take URLs. Drop the attributes when they have prohibited URLs (after trimming whitespace from the value).
** Resolve relative URLs into absolute ones using a per fragment base URL. (Is this correct for Gecko reqs? Current code uses the node's base URI. Is that right?)
** However, allow any URL in the src attribute on the img element, because imgs are safe. {{bug|572637}}
* Have a list of SVG attributes that take different-document references.
* Have a list of SVG attributes that are allowed to have same-document references only.
* If styles are allowed, sanitize style attribute values. If styles aren't allowed, drop the style attribute.
* Always drop script and title elements and their contents.
* If styles are disabled, drop style elements and their contents.
* If styles are enabled, sanitize the content of style elements.
* Add the controls attribute to the video and audio elements (if it isn't there already).

==Open Questions==

* Can stylistic SVG attributes have values that need to be sanitized?
* Should Semantic MathML be on the white list for clipboard round-tripping? (Mainly a footprint issue.)
* Is it dangerous for SVG fragment id references to be able to refer to an id in the document the untrusted fragment gets inserted into?
* What to do about HTML5 microdata?

==Non-Gecko Requirements==

These are features for the HTML5 parser when it is used outside Gecko.

* Allow form-related elements to be toggled on and off in the white list.
* Allow using the sanitizer in non-fragment mode (in which case, the title element should be allowed).
** Are there compelling use cases for non-fragment mode sanitization?
* Have a configurable white list of permitted URL schemes in attributes that take URLs.

Platform/HTML5 sanitizer

2011-01-11T18:26:23Z

Hsivonen: /* Gecko Requirements */

==Gecko Requirements==

* Allow a setting for enabling styles.
* Allow a setting for enabling comments. See {{bug|572642}}
** Or always enable comments? (What about "--" in comments?)
* Have three element white lists: HTML, SVG and MathML.
* Have three attribute white lists: HTML, SVG and MathML. The attributes don't depend on the element they are on beyond the element namespace.
** XXX: Figure out what the requirements are for attributes starting with data- or _.
* Have three lists of attributes that take URLs. Drop the attributes when they have prohibited URLs (after trimming whitespace from the value).
** Resolve relative URLs into absolute ones using a per fragment base URL. (Is this correct for Gecko reqs? Current code uses the node's base URI. Is that right?)
** Why is whitespace trimmed before the security check?
** However, allow any URL in the src attribute on the img element, because imgs are safe. {{bug|572637}}
* Have a list of SVG attributes that take different-document references.
* Have a list of SVG attributes that are allowed to have same-document references only.
* If styles are allowed, sanitize style attribute values. If styles aren't allowed, drop the style attribute.
* Always drop script and title elements and their contents.
* If styles are disabled, drop style elements and their contents.
* If styles are enabled, sanitize the content of style elements.
* Add the controls attribute to the video and audio elements (if it isn't there already).

==Open Questions==

* Can stylistic SVG attributes have values that need to be sanitized?
* Should Semantic MathML be on the white list for clipboard round-tripping? (Mainly a footprint issue.)
* Is it dangerous for SVG fragment id references to be able to refer to an id in the document the untrusted fragment gets inserted into?

==Non-Gecko Requirements==

These are features for the HTML5 parser when it is used outside Gecko.

* Allow form-related elements to be toggled on and off in the white list.
* Allow using the sanitizer in non-fragment mode (in which case, the title element should be allowed).
** Are there compelling use cases for non-fragment mode sanitization?
* Have a configurable white list of permitted URL schemes in attributes that take URLs.

Platform/HTML5 sanitizer

2011-01-11T13:40:29Z

Hsivonen: /* Open Questions */

==Gecko Requirements==

* Allow a setting for enabling styles.
* Allow a setting for enabling comments. See {{bug|572642}}
* Have three element white lists: HTML, SVG and MathML.
* Have three attribute white lists: HTML, SVG and MathML. The attributes don't depend on the element they are on beyond the element namespace.
* Have three lists of attributes that take URLs. Drop the attributes when they have prohibited URLs (after trimming whitespace from the value).
** Resolve relative URLs into absolute ones using a per fragment base URL. (Is this correct for Gecko reqs? Current code uses the node's base URI. Is that right?)
** Why is whitespace trimmed before the security check?
** However, allow any URL in the src attribute on the img element, because imgs are safe. {{bug|572637}}
* Have a list of SVG attributes that take different-document references.
* Have a list of SVG attributes that are allowed to have same-document references only.
* If styles are allowed, sanitize style attribute values. If styles aren't allowed, drop the style attribute.
* Always drop script and title elements and their contents.
* If styles are disabled, drop style elements and their contents.
* If styles are enabled, sanitize the content of style elements.
* Add the controls attribute to the video and audio elements (if it isn't there already).

==Open Questions==

* Can stylistic SVG attributes have values that need to be sanitized?
* Should Semantic MathML be on the white list for clipboard round-tripping? (Mainly a footprint issue.)
* Is it dangerous for SVG fragment id references to be able to refer to an id in the document the untrusted fragment gets inserted into?

==Non-Gecko Requirements==

These are features for the HTML5 parser when it is used outside Gecko.

* Allow form-related elements to be toggled on and off in the white list.
* Allow using the sanitizer in non-fragment mode (in which case, the title element should be allowed).
** Are there compelling use cases for non-fragment mode sanitization?
* Have a configurable white list of permitted URL schemes in attributes that take URLs.