Adding upstream version 124.0.1.upstream/124.0.1

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

28 files changed, 3022 insertions, 0 deletions

diff --git a/testing/mozbase/docs/Makefile b/testing/mozbase/docs/Makefile
new file mode 100644
index 0000000000..386a52db13
--- /dev/null
+++ b/testing/mozbase/docs/Makefile
@@ -0,0 +1,153 @@
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+PAPER         =
+BUILDDIR      = _build
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html       to make standalone HTML files"
+	@echo "  dirhtml    to make HTML files named index.html in directories"
+	@echo "  singlehtml to make a single large HTML file"
+	@echo "  pickle     to make pickle files"
+	@echo "  json       to make JSON files"
+	@echo "  htmlhelp   to make HTML files and a HTML help project"
+	@echo "  qthelp     to make HTML files and a qthelp project"
+	@echo "  devhelp    to make HTML files and a Devhelp project"
+	@echo "  epub       to make an epub"
+	@echo "  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+	@echo "  latexpdf   to make LaTeX files and run them through pdflatex"
+	@echo "  text       to make text files"
+	@echo "  man        to make manual pages"
+	@echo "  texinfo    to make Texinfo files"
+	@echo "  info       to make Texinfo files and run them through makeinfo"
+	@echo "  gettext    to make PO message catalogs"
+	@echo "  changes    to make an overview of all changed/added/deprecated items"
+	@echo "  linkcheck  to check all external links for integrity"
+	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"
+
+clean:
+	-rm -rf $(BUILDDIR)/*
+
+html:
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
+
+dirhtml:
+	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
+
+singlehtml:
+	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
+	@echo
+	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
+
+pickle:
+	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
+	@echo
+	@echo "Build finished; now you can process the pickle files."
+
+json:
+	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
+	@echo
+	@echo "Build finished; now you can process the JSON files."
+
+htmlhelp:
+	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
+	@echo
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      ".hhp project file in $(BUILDDIR)/htmlhelp."
+
+qthelp:
+	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
+	@echo
+	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
+	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
+	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/MozBase.qhcp"
+	@echo "To view the help file:"
+	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/MozBase.qhc"
+
+devhelp:
+	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
+	@echo
+	@echo "Build finished."
+	@echo "To view the help file:"
+	@echo "# mkdir -p $$HOME/.local/share/devhelp/MozBase"
+	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/MozBase"
+	@echo "# devhelp"
+
+epub:
+	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
+	@echo
+	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
+
+latex:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo
+	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
+	@echo "Run \`make' in that directory to run these through (pdf)latex" \
+	      "(use \`make latexpdf' here to do that automatically)."
+
+latexpdf:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo "Running LaTeX files through pdflatex..."
+	$(MAKE) -C $(BUILDDIR)/latex all-pdf
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+text:
+	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
+	@echo
+	@echo "Build finished. The text files are in $(BUILDDIR)/text."
+
+man:
+	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
+	@echo
+	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
+
+texinfo:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo
+	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
+	@echo "Run \`make' in that directory to run these through makeinfo" \
+	      "(use \`make info' here to do that automatically)."
+
+info:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo "Running Texinfo files through makeinfo..."
+	make -C $(BUILDDIR)/texinfo info
+	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
+
+gettext:
+	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
+	@echo
+	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
+
+changes:
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
+	@echo
+	@echo "The overview file is in $(BUILDDIR)/changes."
+
+linkcheck:
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in $(BUILDDIR)/linkcheck/output.txt."
+
+doctest:
+	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
+	@echo "Testing of doctests in the sources finished, look at the " \
+	      "results in $(BUILDDIR)/doctest/output.txt."
diff --git a/testing/mozbase/docs/_static/structured_example.py b/testing/mozbase/docs/_static/structured_example.py
new file mode 100644
index 0000000000..3ec1aa8dcc
--- /dev/null
+++ b/testing/mozbase/docs/_static/structured_example.py
@@ -0,0 +1,111 @@
+# This Source Code Form is subject to the terms of the Mozilla Public
+# License, v. 2.0. If a copy of the MPL was not distributed with this
+# file, You can obtain one at http://mozilla.org/MPL/2.0/.
+
+import argparse
+import sys
+import traceback
+import types
+
+import six
+from mozlog import commandline, get_default_logger
+
+
+class TestAssertion(Exception):
+    pass
+
+
+def assert_equals(a, b):
+    if a != b:
+        raise TestAssertion("%r not equal to %r" % (a, b))
+
+
+def expected(status):
+    def inner(f):
+        def test_func():
+            f()
+
+        test_func.__name__ = f.__name__
+        test_func._expected = status
+        return test_func
+
+    return inner
+
+
+def test_that_passes():
+    assert_equals(1, int("1"))
+
+
+def test_that_fails():
+    assert_equals(1, int("2"))
+
+
+def test_that_has_an_error():
+    assert_equals(2, 1 + "1")
+
+
+@expected("FAIL")
+def test_expected_fail():
+    assert_equals(2 + 2, 5)
+
+
+class TestRunner(object):
+    def __init__(self):
+        self.logger = get_default_logger(component="TestRunner")
+
+    def gather_tests(self):
+        for item in six.itervalues(globals()):
+            if isinstance(item, types.FunctionType) and item.__name__.startswith(
+                "test_"
+            ):
+                yield item.__name__, item
+
+    def run(self):
+        tests = list(self.gather_tests())
+
+        self.logger.suite_start(tests=[name for name, func in tests])
+        self.logger.info("Running tests")
+        for name, func in tests:
+            self.run_test(name, func)
+        self.logger.suite_end()
+
+    def run_test(self, name, func):
+        self.logger.test_start(name)
+        status = None
+        message = None
+        expected = func._expected if hasattr(func, "_expected") else "PASS"
+        try:
+            func()
+        except TestAssertion as e:
+            status = "FAIL"
+            message = str(e)
+        except Exception:
+            status = "ERROR"
+            message = traceback.format_exc()
+        else:
+            status = "PASS"
+        self.logger.test_end(name, status=status, expected=expected, message=message)
+
+
+def get_parser():
+    parser = argparse.ArgumentParser()
+    return parser
+
+
+def main():
+    parser = get_parser()
+    commandline.add_logging_group(parser)
+
+    args = parser.parse_args()
+
+    logger = commandline.setup_logging("structured-example", args, {"raw": sys.stdout})
+
+    runner = TestRunner()
+    try:
+        runner.run()
+    except Exception:
+        logger.critical("Error during test run:\n%s" % traceback.format_exc())
+
+
+if __name__ == "__main__":
+    main()
diff --git a/testing/mozbase/docs/conf.py b/testing/mozbase/docs/conf.py
new file mode 100644
index 0000000000..7855e250b8
--- /dev/null
+++ b/testing/mozbase/docs/conf.py
@@ -0,0 +1,280 @@
+# -*- coding: utf-8 -*-
+#
+# MozBase documentation build configuration file, created by
+# sphinx-quickstart on Mon Oct 22 14:02:17 2012.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import os
+import sys
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+here = os.path.dirname(os.path.abspath(__file__))
+parent = os.path.dirname(here)
+for item in os.listdir(parent):
+    path = os.path.join(parent, item)
+    if (not os.path.isdir(path)) or (
+        not os.path.exists(os.path.join(path, "setup.py"))
+    ):
+        continue
+    sys.path.insert(0, path)
+
+# -- General configuration -----------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+# needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be extensions
+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+extensions = [
+    "sphinx.ext.autodoc",
+    "sphinx.ext.doctest",
+    "sphinx.ext.todo",
+    "sphinx.ext.viewcode",
+]
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ["_templates"]
+
+# The suffix of source filenames.
+source_suffix = ".rst"
+
+# The encoding of source files.
+# source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = "index"
+
+# General information about the project.
+project = "MozBase"
+copyright = "2012, Mozilla Automation and Tools team"
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = "1"
+# The full version, including alpha/beta/rc tags.
+release = "1"
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+# language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+# today = ''
+# Else, today_fmt is used as the format for a strftime call.
+# today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = ["_build"]
+
+# The reST default role (used for this markup: `text`) to use for all documents.
+# default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+# add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+# add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+# show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = "sphinx"
+
+# A list of ignored prefixes for module index sorting.
+# modindex_common_prefix = []
+
+
+# -- Options for HTML output ---------------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+html_theme = "default"
+on_rtd = os.environ.get("READTHEDOCS", None) == "True"
+
+if not on_rtd:
+    try:
+        import sphinx_rtd_theme
+
+        html_theme = "sphinx_rtd_theme"
+        html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
+    except ImportError:
+        pass
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+# html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+# html_theme_path = []
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+html_title = "mozbase documentation"
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+# html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+# html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+# html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ["_static"]
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+# html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+# html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+# html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+# html_additional_pages = {}
+
+# If false, no module index is generated.
+# html_domain_indices = True
+
+# If false, no index is generated.
+# html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+# html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+# html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+# html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+html_show_copyright = False
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+# html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+# html_file_suffix = None
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = "MozBasedoc"
+
+
+# -- Options for LaTeX output --------------------------------------------------
+
+latex_elements = {
+    # The paper size ('letterpaper' or 'a4paper').
+    # 'papersize': 'letterpaper',
+    # The font size ('10pt', '11pt' or '12pt').
+    # 'pointsize': '10pt',
+    # Additional stuff for the LaTeX preamble.
+    # 'preamble': '',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, documentclass [howto/manual]).
+latex_documents = [
+    (
+        "index",
+        "MozBase.tex",
+        "MozBase Documentation",
+        "Mozilla Automation and Tools team",
+        "manual",
+    ),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+# latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+# latex_use_parts = False
+
+# If true, show page references after internal links.
+# latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+# latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+# latex_appendices = []
+
+# If false, no module index is generated.
+# latex_domain_indices = True
+
+
+# -- Options for manual page output --------------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    (
+        "index",
+        "mozbase",
+        "MozBase Documentation",
+        ["Mozilla Automation and Tools team"],
+        1,
+    )
+]
+
+# If true, show URL addresses after external links.
+# man_show_urls = False
+
+
+# -- Options for Texinfo output ------------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+#  dir menu entry, description, category)
+texinfo_documents = [
+    (
+        "index",
+        "MozBase",
+        "MozBase Documentation",
+        "Mozilla Automation and Tools team",
+        "MozBase",
+        "One line description of project.",
+        "Miscellaneous",
+    ),
+]
+
+# Documents to append as an appendix to all manuals.
+# texinfo_appendices = []
+
+# If false, no module index is generated.
+# texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+# texinfo_show_urls = 'footnote'
diff --git a/testing/mozbase/docs/devicemanagement.rst b/testing/mozbase/docs/devicemanagement.rst
new file mode 100644
index 0000000000..e2c229b3b4
--- /dev/null
+++ b/testing/mozbase/docs/devicemanagement.rst
@@ -0,0 +1,11 @@
+Device management
+-----------------
+
+Mozbase provides a module called `mozdevice` for the purposes of
+running automated tests or scripts on an Android phone, tablet, or
+emulator connected to a workstation.
+
+.. toctree::
+   :maxdepth: 3
+
+   mozdevice
diff --git a/testing/mozbase/docs/gettinginfo.rst b/testing/mozbase/docs/gettinginfo.rst
new file mode 100644
index 0000000000..35c4c45081
--- /dev/null
+++ b/testing/mozbase/docs/gettinginfo.rst
@@ -0,0 +1,13 @@
+Getting information on the system under test
+============================================
+
+It's often necessary to get some information about the system we're
+testing, for example to turn on or off some platform specific
+behaviour.
+
+.. toctree::
+   :maxdepth: 2
+
+   mozinfo
+   moznetwork
+   mozversion
diff --git a/testing/mozbase/docs/index.rst b/testing/mozbase/docs/index.rst
new file mode 100644
index 0000000000..f63f0aa68d
--- /dev/null
+++ b/testing/mozbase/docs/index.rst
@@ -0,0 +1,44 @@
+.. MozBase documentation master file, created by
+   sphinx-quickstart on Mon Oct 22 14:02:17 2012.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+mozbase
+=======
+
+Mozbase is a set of easy-to-use Python packages forming a supplemental standard
+library for Mozilla. It provides consistency and reduces redundancy in
+automation and other system-level software. All of Mozilla's test harnesses use
+mozbase to some degree, including Talos_, mochitest_, and reftest_.
+
+.. _Talos: https://wiki.mozilla.org/Talos
+
+.. _mochitest: https://developer.mozilla.org/en-US/docs/Mochitest
+
+.. _reftest: https://developer.mozilla.org/en-US/docs/Creating_reftest-based_unit_tests
+
+In the course of writing automated tests at Mozilla, we found that
+the same tasks came up over and over, regardless of the specific nature of
+what we were testing. We figured that consolidating this code into a set of
+libraries would save us a good deal of time, and so we spent some effort
+factoring out the best-of-breed automation code into something we named
+"mozbase" (usually written all in lower case except at the beginning of a
+sentence).
+
+This is the main documentation for users of mozbase. There is also a
+project_ wiki page with notes on development practices and administration.
+
+.. _project: https://wiki.mozilla.org/Auto-tools/Projects/Mozbase
+
+The documentation is organized by category, then by module. Figure out what you
+want to do then dive in!
+
+.. toctree::
+   :maxdepth: 2
+
+   manifestparser
+   gettinginfo
+   setuprunning
+   servingcontent
+   loggingreporting
+   devicemanagement
diff --git a/testing/mozbase/docs/loggingreporting.rst b/testing/mozbase/docs/loggingreporting.rst
new file mode 100644
index 0000000000..a8561a49b2
--- /dev/null
+++ b/testing/mozbase/docs/loggingreporting.rst
@@ -0,0 +1,11 @@
+Logging and reporting
+=====================
+
+Ideally output between different types of testing system should be as
+uniform as possible, as well as making it easy to make things more or
+less verbose. We created some libraries to make doing this easy.
+
+.. toctree::
+   :maxdepth: 2
+
+   mozlog
diff --git a/testing/mozbase/docs/make.bat b/testing/mozbase/docs/make.bat
new file mode 100644
index 0000000000..d67c86ae98
--- /dev/null
+++ b/testing/mozbase/docs/make.bat
@@ -0,0 +1,190 @@
+@ECHO OFF
+
+REM Command file for Sphinx documentation
+
+if "%SPHINXBUILD%" == "" (
+	set SPHINXBUILD=sphinx-build
+)
+set BUILDDIR=_build
+set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% .
+set I18NSPHINXOPTS=%SPHINXOPTS% .
+if NOT "%PAPER%" == "" (
+	set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%
+	set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS%
+)
+
+if "%1" == "" goto help
+
+if "%1" == "help" (
+	:help
+	echo.Please use `make ^<target^>` where ^<target^> is one of
+	echo.  html       to make standalone HTML files
+	echo.  dirhtml    to make HTML files named index.html in directories
+	echo.  singlehtml to make a single large HTML file
+	echo.  pickle     to make pickle files
+	echo.  json       to make JSON files
+	echo.  htmlhelp   to make HTML files and a HTML help project
+	echo.  qthelp     to make HTML files and a qthelp project
+	echo.  devhelp    to make HTML files and a Devhelp project
+	echo.  epub       to make an epub
+	echo.  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter
+	echo.  text       to make text files
+	echo.  man        to make manual pages
+	echo.  texinfo    to make Texinfo files
+	echo.  gettext    to make PO message catalogs
+	echo.  changes    to make an overview over all changed/added/deprecated items
+	echo.  linkcheck  to check all external links for integrity
+	echo.  doctest    to run all doctests embedded in the documentation if enabled
+	goto end
+)
+
+if "%1" == "clean" (
+	for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i
+	del /q /s %BUILDDIR%\*
+	goto end
+)
+
+if "%1" == "html" (
+	%SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished. The HTML pages are in %BUILDDIR%/html.
+	goto end
+)
+
+if "%1" == "dirhtml" (
+	%SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml.
+	goto end
+)
+
+if "%1" == "singlehtml" (
+	%SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml.
+	goto end
+)
+
+if "%1" == "pickle" (
+	%SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished; now you can process the pickle files.
+	goto end
+)
+
+if "%1" == "json" (
+	%SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished; now you can process the JSON files.
+	goto end
+)
+
+if "%1" == "htmlhelp" (
+	%SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished; now you can run HTML Help Workshop with the ^
+.hhp project file in %BUILDDIR%/htmlhelp.
+	goto end
+)
+
+if "%1" == "qthelp" (
+	%SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished; now you can run "qcollectiongenerator" with the ^
+.qhcp project file in %BUILDDIR%/qthelp, like this:
+	echo.^> qcollectiongenerator %BUILDDIR%\qthelp\MozBase.qhcp
+	echo.To view the help file:
+	echo.^> assistant -collectionFile %BUILDDIR%\qthelp\MozBase.ghc
+	goto end
+)
+
+if "%1" == "devhelp" (
+	%SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished.
+	goto end
+)
+
+if "%1" == "epub" (
+	%SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished. The epub file is in %BUILDDIR%/epub.
+	goto end
+)
+
+if "%1" == "latex" (
+	%SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished; the LaTeX files are in %BUILDDIR%/latex.
+	goto end
+)
+
+if "%1" == "text" (
+	%SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished. The text files are in %BUILDDIR%/text.
+	goto end
+)
+
+if "%1" == "man" (
+	%SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished. The manual pages are in %BUILDDIR%/man.
+	goto end
+)
+
+if "%1" == "texinfo" (
+	%SPHINXBUILD% -b texinfo %ALLSPHINXOPTS% %BUILDDIR%/texinfo
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished. The Texinfo files are in %BUILDDIR%/texinfo.
+	goto end
+)
+
+if "%1" == "gettext" (
+	%SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Build finished. The message catalogs are in %BUILDDIR%/locale.
+	goto end
+)
+
+if "%1" == "changes" (
+	%SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.The overview file is in %BUILDDIR%/changes.
+	goto end
+)
+
+if "%1" == "linkcheck" (
+	%SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Link check complete; look for any errors in the above output ^
+or in %BUILDDIR%/linkcheck/output.txt.
+	goto end
+)
+
+if "%1" == "doctest" (
+	%SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest
+	if errorlevel 1 exit /b 1
+	echo.
+	echo.Testing of doctests in the sources finished, look at the ^
+results in %BUILDDIR%/doctest/output.txt.
+	goto end
+)
+
+:end
diff --git a/testing/mozbase/docs/manifestparser.rst b/testing/mozbase/docs/manifestparser.rst
new file mode 100644
index 0000000000..3ab2f20098
--- /dev/null
+++ b/testing/mozbase/docs/manifestparser.rst
@@ -0,0 +1,648 @@
+Managing lists of tests
+=======================
+
+.. py:currentmodule:: manifestparser
+
+We don't always want to run all tests, all the time. Sometimes a test
+may be broken, in other cases we only want to run a test on a specific
+platform or build of Mozilla. To handle these cases (and more), we
+created a python library to create and use test "manifests", which
+codify this information.
+
+Update for August 2023: Transition to TOML for manifestparser
+`````````````````````````````````````````````````````````````
+
+As of August 2023, manifestparser will be transitioning from INI format
+configuration files to TOML. The new TOML format will better support
+future continuous integration automation and has a much more
+precise syntax (FFI see `Bug 1821199 <https://bugzilla.mozilla.org/show_bug.cgi?id=1821199>`_).
+During the migration period both ``*.ini`` files and
+``*.toml`` files will be supported. If an INI config file is specified
+(e.g. in ``moz.build``) and a TOML file is present, the TOML file will be
+used.
+
+:mod:`manifestparser` --- Create and manage test manifests
+-----------------------------------------------------------
+
+manifestparser lets you easily create and use test manifests, to
+control which tests are run under what circumstances.
+
+What manifestparser gives you:
+
+* manifests are ordered lists of tests
+* tests may have an arbitrary number of key, value pairs
+* the parser returns an ordered list of test data structures, which
+  are just dicts with some keys.  For example, a test with no
+  user-specified metadata looks like this:
+
+.. code-block:: text
+
+    [{'expected': 'pass',
+      'path': '/home/mozilla/mozmill/src/manifestparser/manifestparser/tests/testToolbar/testBackForwardButtons.js',
+      'relpath': 'testToolbar/testBackForwardButtons.js',
+      'name': 'testBackForwardButtons.js',
+      'here': '/home/mozilla/mozmill/src/manifestparser/manifestparser/tests',
+      'manifest': '/home/mozilla/mozmill/src/manifestparser/manifestparser/tests/manifest.toml',}]
+
+The keys displayed here (path, relpath, name, here, and manifest) are
+reserved keys for manifestparser and any consuming APIs.  You can add
+additional key, value metadata to each test.
+
+Why have test manifests?
+````````````````````````
+
+It is desirable to have a unified format for test manifests for testing
+`mozilla-central <http://hg.mozilla.org/mozilla-central>`_, etc.
+
+* It is desirable to be able to selectively enable or disable tests based on platform or other conditions. This should be easy to do. Currently, since many of the harnesses just crawl directories, there is no effective way of disabling a test except for removal from mozilla-central
+* It is desriable to do this in a universal way so that enabling and disabling tests as well as other tasks are easily accessible to a wider audience than just those intimately familiar with the specific test framework.
+* It is desirable to have other metadata on top of the test. For instance, let's say a test is marked as skipped. It would be nice to give the reason why.
+
+
+Most Mozilla test harnesses work by crawling a directory structure.
+While this is straight-forward, manifests offer several practical
+advantages:
+
+* ability to turn a test off easily: if a test is broken on m-c
+  currently, the only way to turn it off, generally speaking, is just
+  removing the test.  Often this is undesirable, as if the test should
+  be dismissed because other people want to land and it can't be
+  investigated in real time (is it a failure? is the test bad? is no
+  one around that knows the test?), then backing out a test is at best
+  problematic.  With a manifest, a test may be disabled without
+  removing it from the tree and a bug filed with the appropriate
+  reason:
+
+.. code-block:: text
+
+     ["test_broken.js"]
+     disabled = "https://bugzilla.mozilla.org/show_bug.cgi?id=123456"
+
+* ability to run different (subsets of) tests on different
+  platforms. Traditionally, we've done a bit of magic or had the test
+  know what platform it would or would not run on. With manifests, you
+  can mark what platforms a test will or will not run on and change
+  these without changing the test.
+
+.. code-block:: text
+
+     ["test_works_on_windows_only.js"]
+     skip-if = ["os != 'win'"]
+
+* ability to markup tests with metadata. We have a large, complicated,
+  and always changing infrastructure.  key, value metadata may be used
+  as an annotation to a test and appropriately curated and mined.  For
+  instance, we could mark certain tests as randomorange with a bug
+  number, if it were desirable.
+
+* ability to have sane and well-defined test-runs. You can keep
+  different manifests for different test runs and ``["include:FILENAME.toml"]``
+  (sub)manifests as appropriate to your needs.
+
+Manifest Format
+```````````````
+
+Manifests are ``*.toml`` (formerly ``*.ini``) files with the section names denoting the path
+relative to the manifest:
+
+.. code-block:: text
+
+    ["foo.js"]
+    ["bar.js"]
+    ["fleem.js"]
+
+The sections are read in order. In addition, tests may include
+arbitrary key, value metadata to be used by the harness.  You may also
+have a `[DEFAULT]` section that will give key, value pairs that will
+be inherited by each test unless overridden:
+
+.. code-block:: text
+
+    [DEFAULT]
+    type = "restart"
+
+    ["lilies.js"]
+    color = "white"
+
+    ["daffodils.js"]
+    color = "yellow"
+    type = "other"
+    # override type from DEFAULT
+
+    ["roses.js"]
+    color = "red"
+
+You can also include other manifests:
+
+.. code-block:: text
+
+    ["include:subdir/anothermanifest.toml"]
+
+And reference parent manifests to inherit keys and values from the DEFAULT
+section, without adding possible included tests.
+
+.. code-block:: text
+
+    ["parent:../manifest.toml"]
+
+Manifests are included relative to the directory of the manifest with
+the `[include:]` directive unless they are absolute paths.
+
+By default you can use '#' as a comment character. Comments can start a
+new line, or be inline.
+
+.. code-block:: text
+
+    ["roses.js"]
+    # a valid comment
+    color = "red" # another valid comment
+
+Because in TOML all values must be quoted there is no risk of an anchor in
+an URL being interpreted as a comment.
+
+.. code-block:: text
+
+    ["test1.js"]
+    url = "https://foo.com/bar#baz" # Bug 1234
+
+
+Manifest Conditional Expressions
+````````````````````````````````
+The conditional expressions used in manifests are parsed using the *ExpressionParser* class.
+
+.. autoclass:: manifestparser.ExpressionParser
+
+Consumers of this module are expected to pass in a value dictionary
+for evaluating conditional expressions. A common pattern is to pass
+the dictionary from the :mod:`mozinfo` module.
+
+Data
+````
+
+Manifest Destiny gives tests as a list of dictionaries (in python
+terms).
+
+* path: full path to the test
+* relpath: relative path starting from the root directory. The root directory
+           is typically the location of the root manifest, or the source
+           repository. It can be specified at runtime by passing in `rootdir`
+           to `TestManifest`. Defaults to the directory containing the test's
+           ancestor manifest.
+* name: file name of the test
+* here: the parent directory of the manifest
+* manifest: the path to the manifest containing the test
+
+This data corresponds to a one-line manifest:
+
+.. code-block:: text
+
+    ["testToolbar/testBackForwardButtons.js"]
+
+If additional key, values were specified, they would be in this dict
+as well.
+
+Outside of the reserved keys, the remaining key, values
+are up to convention to use.  There is a (currently very minimal)
+generic integration layer in manifestparser for use of all harnesses,
+`manifestparser.TestManifest`.
+For instance, if the 'disabled' key is present, you can get the set of
+tests without disabled (various other queries are doable as well).
+
+Since the system is convention-based, the harnesses may do whatever
+they want with the data.  They may ignore it completely, they may use
+the provided integration layer, or they may provide their own
+integration layer.  This should allow whatever sort of logic is
+desired.  For instance, if in yourtestharness you wanted to run only on
+mondays for a certain class of tests:
+
+.. code-block:: text
+
+    tests = []
+    for test in manifests.tests:
+        if 'runOnDay' in test:
+           if calendar.day_name[calendar.weekday(*datetime.datetime.now().timetuple()[:3])].lower() == test['runOnDay'].lower():
+               tests.append(test)
+        else:
+           tests.append(test)
+
+To recap:
+
+* the manifests allow you to specify test data
+* the parser gives you this data
+* you can use it however you want or process it further as you need
+
+Tests are denoted by sections in an ``*.toml`` file (see
+https://searchfox.org/mozilla-central/source/testing/mozbase/manifestparser/tests/manifest.toml
+).
+
+Additional manifest files may be included with an `[include:]` directive:
+
+.. code-block:: text
+
+    ["include:path-to-additional-file-manifest.toml"]
+
+The path to included files is relative to the current manifest.
+
+The `[DEFAULT]` section contains variables that all tests inherit from.
+
+Included files will inherit the top-level variables but may override
+in their own `[DEFAULT]` section.
+
+manifestparser Architecture
+````````````````````````````
+
+There is a two- or three-layered approach to the manifestparser
+architecture, depending on your needs:
+
+1. ManifestParser: this is a generic parser for ``*.toml`` manifests that
+facilitates the `[include:]` logic and the inheritance of
+metadata. Despite the internal variable being called `self.tests`
+(an oversight), this layer has nothing in particular to do with tests.
+
+2. TestManifest: this is a harness-agnostic integration layer that is
+test-specific. TestManifest facilitates `skip-if` logic.
+
+3. Optionally, a harness will have an integration layer than inherits
+from TestManifest if more harness-specific customization is desired at
+the manifest level.
+
+See the source code at
+https://searchfox.org/mozilla-central/source/testing/mozbase/manifestparser
+.
+
+Filtering Manifests
+```````````````````
+
+After creating a `TestManifest` object, all manifest files are read and a list
+of test objects can be accessed via `TestManifest.tests`. However this list contains
+all test objects, whether they should be run or not. Normally they need to be
+filtered down only to the set of tests that should be run by the test harness.
+
+To do this, a test harness can call `TestManifest.active_tests`:
+
+.. code-block:: python
+
+    tests = manifest.active_tests(exists=True, disabled=True, **tags)
+
+By default, `active_tests` runs the filters found in
+:attr:`~.DEFAULT_FILTERS`. It also accepts two convenience arguments:
+
+1. `exists`: if True (default), filter out tests that do not exist on the local file system.
+2. `disabled`: if True (default), do not filter out tests containing the 'disabled' key
+   (which can be set by `skip-if` manually).
+
+This works for simple cases, but there are other built-in filters, or even custom filters
+that can be applied to the `TestManifest`. To do so, add the filter to `TestManifest.filters`:
+
+.. code-block:: python
+
+    from manifestparser.filters import subsuite
+    import mozinfo
+
+    filters = [subsuite('devtools')]
+    tests = manifest.active_tests(filters=filters, **mozinfo.info)
+
+.. automodule:: manifestparser.filters
+    :members:
+    :exclude-members: filterlist,InstanceFilter,DEFAULT_FILTERS
+
+.. autodata::  manifestparser.filters.DEFAULT_FILTERS
+    :annotation:
+
+For example, suppose we want to introduce a new key called `timeout-if` that adds a
+'timeout' property to a test if a certain condition is True. The syntax in the manifest
+files will look like this:
+
+.. code-block:: text
+
+    ["test_foo.py"]
+    timeout-if = ["300, os == 'win'"]
+
+The value is <timeout>, <condition> where condition is the same format as the one in
+`skip-if`. In the above case, if os == 'win', a timeout of 300 seconds will be
+applied. Otherwise, no timeout will be applied. All we need to do is define the filter
+and add it:
+
+.. code-block:: python
+
+    from manifestparser.expression import parse
+    import mozinfo
+
+    def timeout_if(tests, values):
+        for test in tests:
+            if 'timeout-if' in test:
+                timeout, condition = test['timeout-if'].split(',', 1)
+                if parse(condition, **values):
+                    test['timeout'] = timeout
+            yield test
+
+    tests = manifest.active_tests(filters=[timeout_if], **mozinfo.info)
+
+
+CLI
+```
+
+**NOTE:** *The manifestparser CLI is currently being updated to support TOML.*
+
+Run `manifestparser help` for usage information.
+
+To create a manifest from a set of directories:
+
+.. code-block:: text
+
+    manifestparser [options] create directory <directory> <...> [create-options]
+
+To output a manifest of tests:
+
+.. code-block:: text
+
+    manifestparser [options] write manifest <manifest> <...> -tag1 -tag2 --key1=value1 --key2=value2 ...
+
+To copy tests and manifests from a source:
+
+.. code-block:: text
+
+    manifestparser [options] copy from_manifest to_manifest -tag1 -tag2 `key1=value1 key2=value2 ...
+
+To update the tests associated with with a manifest from a source
+directory:
+
+.. code-block:: text
+
+    manifestparser [options] update manifest from_directory -tag1 -tag2 --key1=value1 --key2=value2 ...
+
+Creating Manifests
+``````````````````
+
+manifestparser comes with a console script, `manifestparser create`, that
+may be used to create a seed manifest structure from a directory of
+files.  Run `manifestparser help create` for usage information.
+
+Copying Manifests
+`````````````````
+
+To copy tests and manifests from a source:
+
+.. code-block:: text
+
+    manifestparser [options] copy from_manifest to_directory -tag1 -tag2 `key1=value1 key2=value2 ...
+
+Updating Tests
+``````````````
+
+To update the tests associated with with a manifest from a source
+directory:
+
+.. code-block:: text
+
+    manifestparser [options] update manifest from_directory -tag1 -tag2 `key1=value1 `key2=value2 ...
+
+Usage example
+`````````````
+
+Here is an example of how to create manifests for a directory tree and
+update the tests listed in the manifests from an external source.
+
+Creating Manifests
+``````````````````
+
+Let's say you want to make a series of manifests for a given directory structure containing `.js` test files:
+
+.. code-block:: text
+
+    testing/mozmill/tests/firefox/
+    testing/mozmill/tests/firefox/testAwesomeBar/
+    testing/mozmill/tests/firefox/testPreferences/
+    testing/mozmill/tests/firefox/testPrivateBrowsing/
+    testing/mozmill/tests/firefox/testSessionStore/
+    testing/mozmill/tests/firefox/testTechnicalTools/
+    testing/mozmill/tests/firefox/testToolbar/
+    testing/mozmill/tests/firefox/restartTests
+
+You can use `manifestparser create` to do this:
+
+.. code-block:: text
+
+    $ manifestparser help create
+    Usage: manifestparser.py [options] create directory <directory> <...>
+
+         create a manifest from a list of directories
+
+    Options:
+      -p PATTERN, `pattern=PATTERN
+                            glob pattern for files
+      -i IGNORE, `ignore=IGNORE
+                            directories to ignore
+      -w IN_PLACE, --in-place=IN_PLACE
+                            Write .ini files in place; filename to write to
+
+We only want `.js` files and we want to skip the `restartTests` directory.
+We also want to write a manifest per directory, so I use the `--in-place`
+option to write the manifests:
+
+.. code-block:: text
+
+    manifestparser create . -i restartTests -p '*.js' -w manifest.ini
+
+This creates a manifest.ini per directory that we care about with the JS test files:
+
+.. code-block:: text
+
+    testing/mozmill/tests/firefox/manifest.ini
+    testing/mozmill/tests/firefox/testAwesomeBar/manifest.ini
+    testing/mozmill/tests/firefox/testPreferences/manifest.ini
+    testing/mozmill/tests/firefox/testPrivateBrowsing/manifest.ini
+    testing/mozmill/tests/firefox/testSessionStore/manifest.ini
+    testing/mozmill/tests/firefox/testTechnicalTools/manifest.ini
+    testing/mozmill/tests/firefox/testToolbar/manifest.ini
+
+The top-level `manifest.ini` merely has `[include:]` references to the sub manifests:
+
+.. code-block:: text
+
+    [include:testAwesomeBar/manifest.ini]
+    [include:testPreferences/manifest.ini]
+    [include:testPrivateBrowsing/manifest.ini]
+    [include:testSessionStore/manifest.ini]
+    [include:testTechnicalTools/manifest.ini]
+    [include:testToolbar/manifest.ini]
+
+Each sub-level manifest contains the (`.js`) test files relative to it.
+
+Updating the tests from manifests
+`````````````````````````````````
+
+You may need to update tests as given in manifests from a different source directory.
+`manifestparser update` was made for just this purpose:
+
+.. code-block:: text
+
+    Usage: manifestparser [options] update manifest directory -tag1 -tag2 `key1=value1 --key2=value2 ...
+
+        update the tests as listed in a manifest from a directory
+
+To update from a directory of tests in `~/mozmill/src/mozmill-tests/firefox/` run:
+
+.. code-block:: text
+
+    manifestparser update manifest.ini ~/mozmill/src/mozmill-tests/firefox/
+
+Tests
+`````
+
+manifestparser includes a suite of tests.
+
+`test_manifest.txt` is a doctest that may be helpful in figuring out
+how to use the API.  Tests are run via `mach python-test testing/mozbase/manifestparser`.
+
+Using mach manifest skip-fails
+``````````````````````````````
+
+The first of the ``mach manifest`` subcommands is ``skip-fails``. This command
+can be used to *automatically* edit manifests to skip tests that are failing
+as well as file the corresponding bugs for the failures. This is particularly
+useful when "greening up" a new platform.
+
+You may verify the proposed changes from ``skip-fails`` output and examine
+any local manifest changes with ``hg status``.
+
+Here is the usage:
+
+.. code-block:: text
+
+    $ ./mach manifest skip-fails --help
+    usage: mach [global arguments] manifest skip-fails [command arguments]
+
+    Sub Command Arguments:
+    try_url               Treeherder URL for try (please use quotes)
+    -b BUGZILLA, --bugzilla BUGZILLA
+                            Bugzilla instance
+    -m META_BUG_ID, --meta-bug-id META_BUG_ID
+                            Meta Bug id
+    -s, --turbo           Skip all secondary failures
+    -t SAVE_TASKS, --save-tasks SAVE_TASKS
+                            Save tasks to file
+    -T USE_TASKS, --use-tasks USE_TASKS
+                            Use tasks from file
+    -f SAVE_FAILURES, --save-failures SAVE_FAILURES
+                            Save failures to file
+    -F USE_FAILURES, --use-failures USE_FAILURES
+                            Use failures from file
+    -M MAX_FAILURES, --max-failures MAX_FAILURES
+                            Maximum number of failures to skip (-1 == no limit)
+    -v, --verbose         Verbose mode
+    -d, --dry-run         Determine manifest changes, but do not write them
+    $
+
+``try_url`` --- Treeherder URL
+------------------------------
+This is the url (usually in single quotes) from running tests in try, for example:
+'https://treeherder.mozilla.org/jobs?repo=try&revision=babc28f495ee8af2e4f059e9cbd23e84efab7d0d'
+
+``--bugzilla BUGZILLA`` --- Bugzilla instance
+---------------------------------------------
+
+By default the Bugzilla instance is ``bugzilla.allizom.org``, but you may set it on the command
+line to another value such as ``bugzilla.mozilla.org`` (or by setting the environment variable
+``BUGZILLA``).
+
+``--meta-bug-id META_BUG_ID`` --- Meta Bug id
+---------------------------------------------
+
+Any new bugs that are filed will block (be dependents of) this "meta" bug (optional).
+
+``--turbo`` --- Skip all secondary failures
+-------------------------------------------
+
+The default ``skip-fails`` behavior is to skip only the first failure (for a given label) for each test.
+In `turbo` mode, all failures for this manifest + label will skipped.
+
+``--save-tasks SAVE_TASKS`` --- Save tasks to file
+--------------------------------------------------
+
+This feature is primarily for ``skip-fails`` development and debugging.
+It will save the tasks (downloaded via mozci) to the specified JSON file
+(which may be used in a future ``--use-tasks`` option)
+
+``--use-tasks USE_TASKS`` --- Use tasks from file
+-------------------------------------------------
+This feature is primarily for ``skip-fails`` development and debugging.
+It will uses the tasks from the specified JSON file (instead of downloading them via mozci).
+See also ``--save-tasks``.
+
+``--save-failures SAVE_FAILURES`` --- Save failures to file
+-----------------------------------------------------------
+
+This feature is primarily for ``skip-fails`` development and debugging.
+It will save the failures (calculated from the tasks) to the specified JSON file
+(which may be used in a future ``--use-failures`` option)
+
+``--use-failures USE_FAILURES`` --- Use failures from file
+----------------------------------------------------------
+This feature is primarily for ``skip-fails`` development and debugging.
+It will uses the failures from the specified JSON file (instead of downloading them via mozci).
+See also ``--save-failures``.
+
+``--max-failures MAX_FAILURES`` --- Maximum number of failures to skip
+----------------------------------------------------------------------
+This feature is primarily for ``skip-fails`` development and debugging.
+It will limit the number of failures that are skipped (default is -1 == no limit).
+
+``--verbose`` --- Verbose mode
+------------------------------
+Increase verbosity of output.
+
+``--dry-run`` --- Dry run
+-------------------------
+In dry run mode, the manifest changes (and bugs top be filed) are determined, but not written.
+
+
+Bugs
+````
+
+Please file any bugs or feature requests at
+
+https://bugzilla.mozilla.org/enter_bug.cgi?product=Testing&component=ManifestParser
+
+Or contact in #cia on irc.mozilla.org
+
+Design Considerations
+`````````````````````
+
+Contrary to some opinion, manifestparser.py and the associated ``*.toml``
+format were not magically plucked from the sky but were descended upon
+through several design considerations.
+
+* test manifests should be ordered.  The current ``*.toml`` format supports
+  this (as did the ``*.ini`` format)
+
+* the manifest format should be easily human readable/writable And
+  programmatically editable. While the ``*.ini`` format worked for a long
+  time the underspecified syntax made it difficult to reliably parse.
+  The new ``*.toml`` format is widely accepted, as a formal syntax as well
+  as libraries to read and edit it (e.g. ``tomlkit``).
+
+* there should be a single file that may easily be
+  transported. Traditionally, test harnesses have lived in
+  mozilla-central. This is less true these days and it is increasingly
+  likely that more tests will not live in mozilla-central going
+  forward.  So `manifestparser.py` should be highly consumable. To
+  this end, it is a single file, as appropriate to mozilla-central,
+  which is also a working python package deployed to PyPI for easy
+  installation.
+
+Historical Reference
+````````````````````
+
+Date-ordered list of links about how manifests came to be where they are today::
+
+* https://wiki.mozilla.org/Auto-tools/Projects/UniversalManifest
+* http://alice.nodelman.net/blog/post/2010/05/
+* http://alice.nodelman.net/blog/post/universal-manifest-for-unit-tests-a-proposal/
+* https://elvis314.wordpress.com/2010/07/05/improving-personal-hygiene-by-adjusting-mochitests/
+* https://elvis314.wordpress.com/2010/07/27/types-of-data-we-care-about-in-a-manifest/
+* https://bugzilla.mozilla.org/show_bug.cgi?id=585106
+* http://elvis314.wordpress.com/2011/05/20/converting-xpcshell-from-listing-directories-to-a-manifest/
+* https://bugzilla.mozilla.org/show_bug.cgi?id=616999
+* https://developer.mozilla.org/en/Writing_xpcshell-based_unit_tests#Adding_your_tests_to_the_xpcshell_manifest
+* https://bugzilla.mozilla.org/show_bug.cgi?id=1821199
diff --git a/testing/mozbase/docs/mozcrash.rst b/testing/mozbase/docs/mozcrash.rst
new file mode 100644
index 0000000000..750c46dd8f
--- /dev/null
+++ b/testing/mozbase/docs/mozcrash.rst
@@ -0,0 +1,8 @@
+:mod:`mozcrash` --- Print stack traces from minidumps left behind by crashed processes
+======================================================================================
+
+Gets stack traces out of processes that have crashed and left behind
+a minidump file using the Google Breakpad library.
+
+.. automodule:: mozcrash
+   :members: check_for_crashes
diff --git a/testing/mozbase/docs/mozdebug.rst b/testing/mozbase/docs/mozdebug.rst
new file mode 100644
index 0000000000..6a4be63f45
--- /dev/null
+++ b/testing/mozbase/docs/mozdebug.rst
@@ -0,0 +1,5 @@
+:mod:`mozdebug` --- Configure and launch compatible debuggers.
+======================================================================================
+
+.. automodule:: mozdebug
+   :members: get_debugger_info, get_default_debugger_name, DebuggerSearch
diff --git a/testing/mozbase/docs/mozdevice.rst b/testing/mozbase/docs/mozdevice.rst
new file mode 100644
index 0000000000..ea95a97d9f
--- /dev/null
+++ b/testing/mozbase/docs/mozdevice.rst
@@ -0,0 +1,8 @@
+:mod:`mozdevice` --- Interact with Android devices
+==================================================
+
+.. automodule:: mozdevice
+    :members:
+    :undoc-members:
+    :inherited-members:
+    :show-inheritance:
diff --git a/testing/mozbase/docs/mozfile.rst b/testing/mozbase/docs/mozfile.rst
new file mode 100644
index 0000000000..3ab5492e90
--- /dev/null
+++ b/testing/mozbase/docs/mozfile.rst
@@ -0,0 +1,9 @@
+:mod:`mozfile` --- File utilities for use in Mozilla testing
+============================================================
+
+mozfile is a convenience library for taking care of some common file-related
+tasks in automated testing, such as extracting files or recursively removing
+directories.
+
+.. automodule:: mozfile
+   :members: extract, extract_tarball, extract_zip, move, remove
diff --git a/testing/mozbase/docs/mozgeckoprofiler.rst b/testing/mozbase/docs/mozgeckoprofiler.rst
new file mode 100644
index 0000000000..8e1ae6090d
--- /dev/null
+++ b/testing/mozbase/docs/mozgeckoprofiler.rst
@@ -0,0 +1,21 @@
+:mod:`mozgeckoprofiler.rst` --- Gecko Profiler utilities
+========================================================
+
+This module contains various utilities to work with the Firefox Profiler, Gecko's
+built-in performance profiler. Gecko itself records the profiles, and can dump them
+out to file once the browser shuts down. This package takes those files, symbolicates
+them (turns raw memory addresses into function or symbol names), and provides utilities
+like opening up a locally stored profile in the Firefox Profiler interface. This
+is done by serving the profiles locally, and opening a custom url in profiler.firefox.com.
+
+:mod:`mozgeckoprofiler.rst` --- File origins in mozgeckoprofiler
+----------------------------------------------------------------
+The symbolication files were originally imported from the following repos,
+with permission from their respective authors. However, since then the code has
+been updated for usage within mozbase.
+
+https://github.com/vdjeric/Snappy-Symbolication-Server/
+https://github.com/mstange/analyze-tryserver-profiles/
+
+The dump_syms_mac binary was copied from the objdir of a Firefox build on Mac. It's a
+byproduct of the regular Firefox build process and gets generated in objdir/dist/host/bin/.
diff --git a/testing/mozbase/docs/mozhttpd.rst b/testing/mozbase/docs/mozhttpd.rst
new file mode 100644
index 0000000000..172744e603
--- /dev/null
+++ b/testing/mozbase/docs/mozhttpd.rst
@@ -0,0 +1,22 @@
+
+:mod:`mozhttpd` --- Serving up content to be consumed by the browser
+====================================================================
+
+
+.. warning:: The mozhttpd module is considered obsolete. For new code,
+             please use wptserve_ which can do everything mozhttpd does
+             and more.
+
+.. _wptserve: https://pypi.python.org/pypi/wptserve
+
+:mod:`mozhttpd` --- Simple webserver
+------------------------------------
+
+.. automodule:: mozhttpd
+   :members:
+
+Interface
+`````````
+
+.. autoclass:: MozHttpd
+   :members:
diff --git a/testing/mozbase/docs/mozinfo.rst b/testing/mozbase/docs/mozinfo.rst
new file mode 100644
index 0000000000..c31ff9f702
--- /dev/null
+++ b/testing/mozbase/docs/mozinfo.rst
@@ -0,0 +1,70 @@
+:mod:`mozinfo` --- Get system information
+=========================================
+
+Throughout Mozilla python code, checking the underlying
+platform is done in many different ways.  The various checks needed
+lead to a lot of copy+pasting, leaving the reader to wonder....is this
+specific check necessary for (e.g.) an operating system?  Because
+information is not consolidated, checks are not done consistently, nor
+is it defined what we are checking for.
+
+`mozinfo <https://hg.mozilla.org/mozilla-central/file/tip/testing/mozbase/mozinfo>`_
+proposes to solve this problem.  mozinfo is a bridge interface,
+making the underlying (complex) plethora of OS and architecture
+combinations conform to a subset of values of relevance to
+Mozilla software. The current implementation exposes relevant keys and
+values such as: ``os``, ``version``, ``bits``, and ``processor``.  Additionally, the
+service pack in use is available on the windows platform.
+
+
+API Usage
+---------
+
+mozinfo is a python package.  Downloading the software and running
+``python setup.py develop`` will allow you to do ``import mozinfo``
+from python.
+`mozinfo.py <https://hg.mozilla.org/mozilla-central/file/tip/testing/mozbase/mozinfo/mozinfo/mozinfo.py>`_
+is the only file contained in this package,
+so if you need a single-file solution, you can just download or call
+this file through the web.
+
+The top level attributes (``os``, ``version``, ``bits``, ``processor``) are
+available as module globals::
+
+    if mozinfo.os == 'win': ...
+
+In addition, mozinfo exports a dictionary, ``mozinfo.info``, that
+contain these values.  mozinfo also exports:
+
+- ``choices``: a dictionary of possible values for os, bits, and
+  processor
+- ``main``: the console_script entry point for mozinfo
+- ``unknown``: a singleton denoting a value that cannot be determined
+
+``unknown`` has the string representation ``"UNKNOWN"``.
+``unknown`` will evaluate as ``False`` in python::
+
+    if not mozinfo.os: ... # unknown!
+
+
+Command Line Usage
+------------------
+
+mozinfo comes with a command line program, ``mozinfo`` which may be used to
+diagnose one's current system.
+
+Example output::
+
+    os: linux
+    version: Ubuntu 10.10
+    bits: 32
+    processor: x86
+
+Three of these fields, os, bits, and processor, have a finite set of
+choices.  You may display the value of these choices using
+``mozinfo --os``, ``mozinfo --bits``, and ``mozinfo --processor``.
+``mozinfo --help`` documents command-line usage.
+
+
+.. automodule:: mozinfo
+   :members:
diff --git a/testing/mozbase/docs/mozinstall.rst b/testing/mozbase/docs/mozinstall.rst
new file mode 100644
index 0000000000..7db40d73de
--- /dev/null
+++ b/testing/mozbase/docs/mozinstall.rst
@@ -0,0 +1,29 @@
+:mod:`mozinstall` --- Install and uninstall Gecko-based applications
+====================================================================
+
+mozinstall is a small python module with several convenience methods
+useful for installing and uninstalling a gecko-based application
+(e.g. Firefox) on the desktop.
+
+Simple example
+--------------
+
+::
+
+    import mozinstall
+    import tempfile
+
+    tempdir = tempfile.mkdtemp()
+    firefox_dmg = 'firefox-38.0a1.en-US.mac.dmg'
+    install_folder = mozinstall.install(src=firefox_dmg, dest=tempdir)
+    binary = mozinstall.get_binary(install_folder, 'Firefox')
+    # from here you can execute the binary directly
+    # ...
+    mozinstall.uninstall(install_folder)
+
+API Documentation
+-----------------
+
+.. automodule:: mozinstall
+   :members: is_installer, install, get_binary, uninstall,
+             InstallError, InvalidBinary, InvalidSource
diff --git a/testing/mozbase/docs/mozlog.rst b/testing/mozbase/docs/mozlog.rst
new file mode 100644
index 0000000000..63e3614243
--- /dev/null
+++ b/testing/mozbase/docs/mozlog.rst
@@ -0,0 +1,520 @@
+:mod:`mozlog` --- Structured logging for test output
+===============================================================
+
+:py:mod:`mozlog` is a library designed for logging the
+execution and results of test harnesses. The internal data model is a
+stream of JSON-compatible objects, with one object per log entry. The
+default output format is line-based, with one JSON object serialized
+per line.
+
+:py:mod:`mozlog` is *not* based on the stdlib logging
+module, although it shares several concepts with it.
+
+One notable difference between this module and the standard logging
+module is the way that loggers are created. The structured logging
+module does not require that loggers with a specific name are
+singleton objects accessed through a factory function. Instead the
+``StructuredLogger`` constructor may be used directly. However all
+loggers with the same name share the same internal state (the "Borg"
+pattern). In particular the list of handler functions is the same for
+all loggers with the same name.
+
+Typically, you would only instantiate one logger object per
+program. Two convenience methods are provided to set and get the
+default logger in the program.
+
+Logging is threadsafe, with access to handlers protected by a
+``threading.Lock``. However it is `not` process-safe. This means that
+applications using multiple processes, e.g. via the
+``multiprocessing`` module, should arrange for all logging to happen in
+a single process.
+
+Data Format
+-----------
+
+Structured loggers produce messages in a simple format designed to be
+compatible with the JSON data model. Each message is a single object,
+with the type of message indicated by the ``action`` key. It is
+intended that the set of ``action`` values be closed; where there are
+use cases for additional values they should be integrated into this
+module rather than extended in an ad-hoc way. The set of keys present
+on on all messages is:
+
+``action``
+  The type of the message (string).
+
+``time``
+  The timestamp of the message in ms since the epoch (int).
+
+``thread``
+  The name of the thread emitting the message (string).
+
+``pid``
+  The pid of the process creating the message (int).
+
+``source``
+  Name of the logger creating the message (string).
+
+For each ``action`` there are is a further set of specific fields
+describing the details of the event that caused the message to be
+emitted:
+
+``suite_start``
+  Emitted when the testsuite starts running.
+
+  ``tests``
+    A dict of test ids keyed by group. Groups are any logical grouping
+    of tests, for example a manifest, directory or tag. For convenience,
+    a list of test ids can be used instead. In this case all tests will
+    automatically be placed in the 'default' group name. Test ids can
+    either be strings or lists of strings (an example of the latter is
+    reftests where the id has the form [test_url, ref_type, ref_url]).
+    Test ids are assumed to be unique within a given testsuite. In cases
+    where the test list is not known upfront an empty dict or list may
+    be passed (dict).
+
+  ``name``
+    An optional string to identify the suite by.
+
+  ``run_info``
+    An optional dictionary describing the properties of the
+    build and test environment. This contains the information provided
+    by :doc:`mozinfo <mozinfo>`, plus a boolean ``debug`` field indicating
+    whether the build under test is a debug build.
+
+``suite_end``
+  Emitted when the testsuite is finished and no more results will be produced.
+
+``test_start``
+  Emitted when a test is being started.
+
+  ``test``
+    A unique id for the test (string or list of strings).
+
+  ``path``
+    Optional path to the test relative to some base (typically the root of the
+    source tree). Mainly used when ``test`` id is not a path (string).
+
+``test_status``
+  Emitted for a test which has subtests to record the result of a
+  single subtest.
+
+  ``test``
+    The same unique id for the test as in the ``test_start`` message.
+
+  ``subtest``
+    Name of the subtest (string).
+
+  ``status``
+    Result of the test (string enum; ``PASS``, ``FAIL``,
+    ``PRECONDITION_FAILED``, ``TIMEOUT``, ``NOTRUN``)
+
+  ``expected``
+    Expected result of the test. Omitted if the expected result is the
+    same as the actual result (string enum, same as ``status``).
+
+  ``known_intermittent``
+    A list of known intermittent statuses for that test. Omitted if there are
+    no intermittent statuses expected. (items in the list are string enum, same as ``status``)
+
+``test_end``
+  Emitted to give the result of a test with no subtests, or the status
+  of the overall file when there are subtests.
+
+  ``test``
+    The same unique id for the test as in the ``test_start`` message.
+
+  ``status``
+    Either result of the test (if there are no subtests) in which case
+    (string enum ``PASS``, ``FAIL``, ``PRECONDITION_FAILED``,
+    ``TIMEOUT``, ``CRASH``, ``ASSERT``, , ``SKIP``) or the status of
+    the overall file where there are subtests (string enum ``OK``,
+    ``PRECONDITION_FAILED``, ``ERROR``, ``TIMEOUT``, ``CRASH``,
+    ``ASSERT``, ``SKIP``).
+
+  ``expected``
+    The expected status, or omitted if the expected status matches the
+    actual status (string enum, same as ``status``).
+
+  ``known_intermittent``
+    A list of known intermittent statuses for that test. Omitted if there are
+    no intermittent statuses expected. (items in the list are string enum, same as ``status``)
+
+``process_output``
+  Output from a managed subprocess.
+
+  ``process``
+  pid of the subprocess.
+
+  ``command``
+  Command used to launch the subprocess.
+
+  ``data``
+  Data output by the subprocess.
+
+``log``
+  General human-readable logging message, used to debug the harnesses
+  themselves rather than to provide input to other tools.
+
+  ``level``
+    Level of the log message (string enum ``CRITICAL``, ``ERROR``,
+    ``WARNING``, ``INFO``, ``DEBUG``).
+
+  ``message``
+    Text of the log message.
+
+``shutdown``
+  This is a special action that can only be logged once per logger state.
+  It is sent when calling :meth:`StructuredLogger.shutdown` or implicitly
+  when exiting the context manager.
+
+Testsuite Protocol
+------------------
+
+When used for testsuites, the following structured logging messages must be emitted:
+
+ * One ``suite_start`` message before any ``test_*`` messages
+
+ * One ``test_start`` message per test that is run
+
+ * One ``test_status`` message per subtest that is run. This might be
+   zero if the test type doesn't have the notion of subtests.
+
+ * One ``test_end`` message per test that is run, after the
+   ``test_start`` and any ``test_status`` messages for that same test.
+
+ * One ``suite_end`` message after all ``test_*`` messages have been
+   emitted.
+
+The above mandatory events may be interspersed with ``process_output``
+and ``log`` events, as required.
+
+Subtests
+~~~~~~~~
+
+The purpose of subtests is to deal with situations where a single test
+produces more than one result, and the exact details of the number of
+results is not known ahead of time. For example consider a test
+harness that loads JavaScript-based tests in a browser. Each url
+loaded would be a single test, with corresponding ``test_start`` and
+``test_end`` messages. If there can be more than one JS-defined test
+on a page, however, it it useful to track the results of those tests
+separately. Therefore each of those tests is a subtest, and one
+``test_status`` message must be generated for each subtest result.
+
+Subtests must have a name that is unique within their parent test.
+
+Whether or not a test has subtests changes the meaning of the
+``status`` property on the test itself. When the test does not have
+any subtests, this property is the actual test result such as ``PASS``
+or ``FAIL`` . When a test does have subtests, the test itself does not
+have a result as-such; it isn't meaningful to describe it as having a
+``PASS`` result, especially if the subtests did not all pass. Instead
+this property is used to hold information about whether the test ran
+without error. If no errors were detected the test must be given the
+status ``OK``. Otherwise the test may get the status ``ERROR`` (for
+e.g. uncaught JS exceptions), ``TIMEOUT`` (if no results were reported
+in the allowed time) or ``CRASH`` (if the test caused the process
+under test to crash).
+
+StructuredLogger Objects
+------------------------
+
+.. automodule:: mozlog.structuredlog
+  :members: set_default_logger, get_default_logger, LoggerShutdownError
+
+.. autoclass:: StructuredLogger
+   :members: add_handler, remove_handler, handlers, suite_start,
+             suite_end, test_start, test_status, test_end,
+             process_output, critical, error, warning, info, debug,
+             shutdown
+
+.. autoclass:: StructuredLogFileLike
+  :members:
+
+ProxyLogger Objects
+-------------------
+
+Since :func:`mozlog.structuredlog.get_default_logger` return None when
+the default logger is not initialized, it is not possible to directly
+use it at the module level.
+
+With ProxyLogger, it is possible to write the following code: ::
+
+  from mozlog import get_proxy_logger
+
+  LOG = get_proxy_logger('component_name')
+
+
+  def my_function():
+      LOG.info('logging with a module level object')
+
+
+.. note::
+
+   mozlog still needs to be initialized before the first call occurs
+   to a ProxyLogger instance, for example with
+   :func:`mozlog.commandline.setup_logging`.
+
+.. automodule:: mozlog.proxy
+  :members: get_proxy_logger, ProxyLogger
+
+Handlers
+--------
+
+A handler is a callable that is called for each log message produced
+and is responsible for handling the processing of that
+message. The typical example of this is a ``StreamHandler`` which takes
+a log message, invokes a formatter which converts the log to a string,
+and writes it to a file.
+
+.. automodule:: mozlog.handlers
+
+.. autoclass:: BaseHandler
+  :members:
+
+.. autoclass:: StreamHandler
+  :members:
+
+.. autoclass:: LogLevelFilter
+  :members:
+
+.. autoclass:: BufferHandler
+  :members:
+
+Formatters
+----------
+
+Formatters are callables that take a log message, and return either a
+string representation of that message, or ``None`` if that message
+should not appear in the output. This allows formatters to both
+exclude certain items and create internal buffers of the output so
+that, for example, a single string might be returned for a
+``test_end`` message indicating the overall result of the test,
+including data provided in the ``test_status`` messages.
+
+Formatter modules are written so that they can take raw input on stdin
+and write formatted output on stdout. This allows the formatters to be
+invoked as part of a command line for post-processing raw log files.
+
+.. automodule:: mozlog.formatters.base
+
+.. autoclass:: BaseFormatter
+  :members:
+
+.. automodule:: mozlog.formatters.unittest
+
+.. autoclass:: UnittestFormatter
+  :members:
+
+.. automodule:: mozlog.formatters.xunit
+
+.. autoclass:: XUnitFormatter
+  :members:
+
+.. automodule:: mozlog.formatters.html
+
+.. autoclass:: HTMLFormatter
+  :members:
+
+.. automodule:: mozlog.formatters.machformatter
+
+.. autoclass:: MachFormatter
+  :members:
+
+.. automodule:: mozlog.formatters.tbplformatter
+
+.. autoclass:: TbplFormatter
+  :members:
+
+Processing Log Files
+--------------------
+
+The ``mozlog.reader`` module provides utilities for working
+with structured log files.
+
+.. automodule:: mozlog.reader
+  :members:
+
+Integration with argparse
+-------------------------
+
+The `mozlog.commandline` module provides integration with the `argparse`
+module to provide uniform logging-related command line arguments to programs
+using `mozlog`. Each known formatter gets a command line argument of the form
+``--log-{name}``, which takes the name of a file to log to with that format,
+or ``-`` to indicate stdout.
+
+.. automodule:: mozlog.commandline
+  :members:
+
+Simple Examples
+---------------
+
+Log to stdout::
+
+    from mozlog import structuredlog
+    from mozlog import handlers, formatters
+    logger = structuredlog.StructuredLogger("my-test-suite")
+    logger.add_handler(handlers.StreamHandler(sys.stdout,
+                                              formatters.JSONFormatter()))
+    logger.suite_start(["test-id-1"])
+    logger.test_start("test-id-1")
+    logger.info("This is a message with action='LOG' and level='INFO'")
+    logger.test_status("test-id-1", "subtest-1", "PASS")
+    logger.test_end("test-id-1", "OK")
+    logger.suite_end()
+
+Log with a context manager::
+
+    from mozlog.structuredlog import StructuredLogger
+    from mozlog.handlers import StreamHandler
+    from mozlog.formatters import JSONFormatter
+
+    with StructuredLogger("my-test-suite") as logger:
+        logger.add_handler(StreamHandler(sys.stdout,
+                                         JSONFormatter()))
+        logger.info("This is an info message")
+
+Populate an ``argparse.ArgumentParser`` with logging options, and
+create a logger based on the value of those options, defaulting to
+JSON output on stdout if nothing else is supplied::
+
+   import argparse
+   from mozlog import commandline
+
+   parser = argparse.ArgumentParser()
+   # Here one would populate the parser with other options
+   commandline.add_logging_group(parser)
+
+   args = parser.parse_args()
+   logger = commandline.setup_logging("testsuite-name", args, {"raw": sys.stdout})
+
+Count the number of tests that timed out in a testsuite::
+
+   from mozlog import reader
+
+   count = 0
+
+   def handle_test_end(data):
+       global count
+       if data["status"] == "TIMEOUT":
+           count += 1
+
+   reader.each_log(reader.read("my_test_run.log"),
+                   {"test_end": handle_test_end})
+
+   print count
+
+More Complete Example
+---------------------
+
+This example shows a complete toy testharness set up to used
+structured logging. It is available as `structured_example.py <_static/structured_example.py>`_:
+
+.. literalinclude:: _static/structured_example.py
+
+Each global function with a name starting
+``test_`` represents a test. A passing test returns without
+throwing. A failing test throws a :py:class:`TestAssertion` exception
+via the :py:func:`assert_equals` function. Throwing anything else is
+considered an error in the test. There is also a :py:func:`expected`
+decorator that is used to annotate tests that are expected to do
+something other than pass.
+
+The main entry point to the test runner is via that :py:func:`main`
+function. This is responsible for parsing command line
+arguments, and initiating the test run. Although the test harness
+itself does not provide any command line arguments, the
+:py:class:`ArgumentParser` object is populated by
+:py:meth:`commandline.add_logging_group`, which provides a generic
+set of structured logging arguments appropriate to all tools producing
+structured logging.
+
+The values of these command line arguments are used to create a
+:py:class:`mozlog.StructuredLogger` object populated with the
+specified handlers and formatters in
+:py:func:`commandline.setup_logging`. The third argument to this
+function is the default arguments to use. In this case the default
+is to output raw (i.e. JSON-formatted) logs to stdout.
+
+The main test harness is provided by the :py:class:`TestRunner`
+class. This class is responsible for scheduling all the tests and
+logging all the results. It is passed the :py:obj:`logger` object
+created from the command line arguments. The :py:meth:`run` method
+starts the test run. Before the run is started it logs a
+``suite_start`` message containing the id of each test that will run,
+and after the testrun is done it logs a ``suite_end`` message.
+
+Individual tests are run in the :py:meth:`run_test` method. For each
+test this logs a ``test_start`` message. It then runs the test and
+logs a ``test_end`` message containing the test name, status, expected
+status, and any informational message about the reason for the
+result. In this test harness there are no subtests, so the
+``test_end`` message has the status of the test and there are no
+``test_status`` messages.
+
+Example Output
+~~~~~~~~~~~~~~
+
+When run without providing any command line options, the raw
+structured log messages are sent to stdout::
+
+  $ python structured_example.py
+
+  {"source": "structured-example", "tests": ["test_that_has_an_error", "test_that_fails", "test_expected_fail", "test_that_passes"], "thread": "MainThread", "time": 1401446682787, "action": "suite_start", "pid": 18456}
+  {"source": "structured-example", "thread": "MainThread", "time": 1401446682787, "action": "log", "message": "Running tests", "level": "INFO", "pid": 18456}
+  {"source": "structured-example", "test": "test_that_has_an_error", "thread": "MainThread", "time": 1401446682787, "action": "test_start", "pid": 18456}
+  {"status": "ERROR", "thread": "MainThread", "pid": 18456, "source": "structured-example", "test": "test_that_has_an_error", "time": 1401446682788, "action": "test_end", "message": "Traceback (most recent call last):\n  File \"structured_example.py\", line 61, in run_test\n    func()\n  File \"structured_example.py\", line 31, in test_that_has_an_error\n    assert_equals(2, 1 + \"1\")\nTypeError: unsupported operand type(s) for +: 'int' and 'str'\n", "expected": "PASS"}
+  {"source": "structured-example", "test": "test_that_fails", "thread": "MainThread", "time": 1401446682788, "action": "test_start", "pid": 18456}
+  {"status": "FAIL", "thread": "MainThread", "pid": 18456, "source": "structured-example", "test": "test_that_fails", "time": 1401446682788, "action": "test_end", "message": "1 not equal to 2", "expected": "PASS"}
+  {"source": "structured-example", "test": "test_expected_fail", "thread": "MainThread", "time": 1401446682788, "action": "test_start", "pid": 18456}
+  {"status": "FAIL", "thread": "MainThread", "pid": 18456, "source": "structured-example", "test": "test_expected_fail", "time": 1401446682788, "action": "test_end", "message": "4 not equal to 5"}
+  {"source": "structured-example", "test": "test_that_passes", "thread": "MainThread", "time": 1401446682788, "action": "test_start", "pid": 18456}
+  {"status": "PASS", "source": "structured-example", "test": "test_that_passes", "thread": "MainThread", "time": 1401446682789, "action": "test_end", "pid": 18456}
+  {"source": "structured-example", "test": "test_with_known_intermittent", "thread": "MainThread", "time": 1401446682789, "action": "test_start", "pid": 18456}
+  {"status": "FAIL", thread": "MainThread", "pid": 18456, "source": "structured-example", "test": "test_with_known_intermittent", "time": 1401446682790, "action": "test_end", "expected": "PASS", "known_intermittent": ["FAIL", "TIMEOUT"]}
+  {"action": "suite_end", "source": "structured-example", "pid": 18456, "thread": "MainThread", "time": 1401446682790}
+
+The structured logging module provides a number of command line
+options::
+
+  $ python structured_example.py --help
+
+  usage: structured_example.py [-h] [--log-unittest LOG_UNITTEST]
+                               [--log-raw LOG_RAW] [--log-html LOG_HTML]
+                               [--log-xunit LOG_XUNIT]
+                               [--log-mach LOG_MACH]
+
+  optional arguments:
+    -h, --help            show this help message and exit
+
+  Output Logging:
+    Options for logging output. Each option represents a possible logging
+    format and takes a filename to write that format to, or '-' to write to
+    stdout.
+
+    --log-unittest LOG_UNITTEST
+                          Unittest style output
+    --log-raw LOG_RAW     Raw structured log messages
+    --log-html LOG_HTML   HTML report
+    --log-xunit LOG_XUNIT
+                          xUnit compatible XML
+    --log-mach LOG_MACH   Human-readable output
+
+In order to get human-readable output on stdout and the structured log
+data to go to the file ``structured.log``, we would run::
+
+  $ python structured_example.py --log-mach=- --log-raw=structured.log
+
+  0:00.00 SUITE_START: MainThread 4
+  0:01.00 LOG: MainThread INFO Running tests
+  0:01.00 TEST_START: MainThread test_that_has_an_error
+  0:01.00 TEST_END: MainThread Harness status ERROR, expected PASS. Subtests passed 0/0. Unexpected 1
+  0:01.00 TEST_START: MainThread test_that_fails
+  0:01.00 TEST_END: MainThread Harness status FAIL, expected PASS. Subtests passed 0/0. Unexpected 1
+  0:01.00 TEST_START: MainThread test_expected_fail
+  0:02.00 TEST_END: MainThread Harness status FAIL. Subtests passed 0/0. Unexpected 0
+  0:02.00 TEST_START: MainThread test_that_passes
+  0:02.00 TEST_END: MainThread Harness status PASS. Subtests passed 0/0. Unexpected 0
+  0:02.00 SUITE_END: MainThread
diff --git a/testing/mozbase/docs/moznetwork.rst b/testing/mozbase/docs/moznetwork.rst
new file mode 100644
index 0000000000..905433e8a7
--- /dev/null
+++ b/testing/mozbase/docs/moznetwork.rst
@@ -0,0 +1,8 @@
+:mod:`moznetwork` --- Get network information
+=============================================
+
+.. automodule:: moznetwork
+
+  .. automethod:: moznetwork.get_ip
+
+  .. autoclass:: moznetwork.NetworkError
diff --git a/testing/mozbase/docs/mozpower.rst b/testing/mozbase/docs/mozpower.rst
new file mode 100644
index 0000000000..76be41d987
--- /dev/null
+++ b/testing/mozbase/docs/mozpower.rst
@@ -0,0 +1,112 @@
+:mod:`mozpower` --- Power-usage testing
+=======================================
+
+Mozpower provides an interface through which power usage measurements
+can be done on any OS and CPU combination (auto-detected) that has
+been implemented within the module. It provides 2 methods to start
+and stop the measurement gathering as well as methods to get the
+result that can also be formatted into a perfherder data blob.
+
+Basic Usage
+-----------
+
+Although multiple classes exist within the mozpower module,
+the only one that should be used is MozPower which is accessible
+from the top-level of the module. It handles which subclasses
+should be used depending on the detected OS and CPU combination.
+
+.. code-block:: python
+
+    from mozpower import MozPower
+
+    mp = MozPower(
+        ipg_measure_duration=600,
+        sampling_rate=1000,
+        output_file_path='tempdir/dataprefix'
+    )
+    mp.initialize_power_measurements()
+
+    # Run test TEST_NAME
+
+    mp.finalize_power_measurements(
+        test_name=TEST_NAME,
+        output_dir_path=env['MOZ_UPLOAD_DIR']
+    )
+
+    # Get complete PERFHERDER_DATA
+    perfherder_data = mp.get_full_perfherder_data('raptor')
+
+All the possible known errors that can occur are also provided
+at the top-level of the module.
+
+.. code-block:: python
+
+    from mozpower import MozPower, IPGExecutableMissingError, OsCpuComboMissingError
+
+    try:
+        mp = MozPower(ipg_measure_duration=600, sampling_rate=1000)
+    except IPGExecutableMissingError as e:
+        pass
+    except OsCpuComboMissingError as e:
+        pass
+
+
+.. automodule:: mozpower
+
+.. _MozPower:
+
+MozPower Interface
+------------------
+
+The following class provides a basic interface to interact with the
+power measurement tools that have been implemented. The tool used
+to measure power depends on the OS and CPU combination, i.e. Intel-based
+MacOS machines would use Intel Power Gadget, while ARM64-based Windows
+machines would use the native Windows tool powercfg.
+
+MozPower
+````````
+
+.. autoclass:: mozpower.MozPower
+
+Measurement methods
++++++++++++++++++++
+.. automethod:: MozPower.initialize_power_measurements(self, **kwargs)
+.. automethod:: MozPower.finalize_power_measurements(self, **kwargs)
+
+Informational methods
++++++++++++++++++++++
+.. automethod:: MozPower.get_perfherder_data(self)
+.. automethod:: MozPower.get_full_perfherder_data(self, framework, lowerisbetter=True, alertthreshold=2.0)
+
+IPGEmptyFileError
+`````````````````
+.. autoexception:: mozpower.IPGEmptyFileError
+
+IPGExecutableMissingError
+`````````````````````````
+.. autoexception:: mozpower.IPGExecutableMissingError
+
+IPGMissingOutputFileError
+`````````````````````````
+.. autoexception:: mozpower.IPGMissingOutputFileError
+
+IPGTimeoutError
+```````````````
+.. autoexception:: mozpower.IPGTimeoutError
+
+IPGUnknownValueTypeError
+````````````````````````
+.. autoexception:: mozpower.IPGUnknownValueTypeError
+
+MissingProcessorInfoError
+`````````````````````````
+.. autoexception:: mozpower.MissingProcessorInfoError
+
+OsCpuComboMissingError
+``````````````````````
+.. autoexception:: mozpower.OsCpuComboMissingError
+
+PlatformUnsupportedError
+````````````````````````
+.. autoexception:: mozpower.PlatformUnsupportedError
diff --git a/testing/mozbase/docs/mozprocess.rst b/testing/mozbase/docs/mozprocess.rst
new file mode 100644
index 0000000000..ef90e5aa0c
--- /dev/null
+++ b/testing/mozbase/docs/mozprocess.rst
@@ -0,0 +1,324 @@
+:mod:`mozprocess` --- Launch and manage processes
+=================================================
+
+Mozprocess is a process-handling module that provides some additional
+features beyond those available with python's subprocess:
+
+* better handling of child processes, especially on Windows
+* the ability to timeout the process after some absolute period, or some
+  period without any data written to stdout/stderr
+* the ability to specify output handlers that will be called
+  for each line of output produced by the process
+* the ability to specify handlers that will be called on process timeout
+  and normal process termination
+
+Running a process
+-----------------
+
+mozprocess consists of two classes: ProcessHandler inherits from ProcessHandlerMixin.
+
+Let's see how to run a process.
+First, the class should be instantiated with at least one argument which is a command (or a list formed by the command followed by its arguments).
+Then the process can be launched using the *run()* method.
+Finally the *wait()* method will wait until end of execution.
+
+.. code-block:: python
+
+    from mozprocess import processhandler
+
+    # under Windows replace by command = ['dir', '/a']
+    command = ['ls', '-l']
+    p = processhandler.ProcessHandler(command)
+    print("execute command: %s" % p.commandline)
+    p.run()
+    p.wait()
+
+Note that using *ProcessHandler* instead of *ProcessHandlerMixin* will print the output of executed command. The attribute *commandline* provides the launched command.
+
+Collecting process output
+-------------------------
+
+Let's now consider a basic shell script that will print numbers from 1 to 5 waiting 1 second between each.
+This script will be used as a command to launch in further examples.
+
+**proc_sleep_echo.sh**:
+
+.. code-block:: sh
+
+    #!/bin/sh
+
+    for i in 1 2 3 4 5
+    do
+        echo $i
+        sleep 1
+    done
+
+If you are running under Windows, you won't be able to use the previous script (unless using Cygwin).
+So you'll use the following script:
+
+**proc_sleep_echo.bat**:
+
+.. code-block:: bat
+
+    @echo off
+    FOR %%A IN (1 2 3 4 5) DO (
+        ECHO %%A
+        REM if you have TIMEOUT then use it instead of PING
+        REM TIMEOUT /T 1 /NOBREAK
+        PING -n 2 127.0.0.1 > NUL
+    )
+
+Mozprocess allows the specification of custom output handlers to gather process output while running.
+ProcessHandler will by default write all outputs on stdout. You can also provide (to ProcessHandler or ProcessHandlerMixin) a function or a list of functions that will be used as callbacks on each output line generated by the process.
+
+In the following example the command's output will be stored in a file *output.log* and printed in stdout:
+
+.. code-block:: python
+
+    import sys
+    from mozprocess import processhandler
+
+    fd = open('output.log', 'w')
+
+    def tostdout(line):
+        sys.stdout.write("<%s>\n" % line)
+
+    def tofile(line):
+        fd.write("<%s>\n" % line)
+
+    # under Windows you'll replace by 'proc_sleep_echo.bat'
+    command = './proc_sleep_echo.sh'
+    outputs = [tostdout, tofile]
+
+    p = processhandler.ProcessHandlerMixin(command, processOutputLine=outputs)
+    p.run()
+    p.wait()
+
+    fd.close()
+
+The process output can be saved (*obj = ProcessHandler(..., storeOutput=True)*) so as it is possible to request it (*obj.output*) at any time. Note that the default value for *stroreOutput* is *True*, so it is not necessary to provide it in the parameters.
+
+.. code-block:: python
+
+    import time
+    import sys
+    from mozprocess import processhandler
+
+    command = './proc_sleep_echo.sh' # Windows: 'proc_sleep_echo.bat'
+
+    p = processhandler.ProcessHandler(command, storeOutput=True)
+    p.run()
+    for i in xrange(10):
+        print(p.output)
+        time.sleep(0.5)
+    p.wait()
+
+In previous example, you will see the *p.output* list growing.
+
+Execution
+---------
+
+Status
+``````
+
+It is possible to query the status of the process via *poll()* that will return None if the process is still running, 0 if it ended without failures and a negative value if it was killed by a signal (Unix-only).
+
+.. code-block:: python
+
+    import time
+    import signal
+    from mozprocess import processhandler
+
+    command = './proc_sleep_echo.sh'
+    p = processhandler.ProcessHandler(command)
+    p.run()
+    time.sleep(2)
+    print("poll status: %s" % p.poll())
+    time.sleep(1)
+    p.kill(signal.SIGKILL)
+    print("poll status: %s" % p.poll())
+
+Timeout
+```````
+
+A timeout can be provided to the *run()* method. If the process last more than timeout seconds, it will be stopped.
+
+After execution, the property *timedOut* will be set to True if a timeout was reached.
+
+It is also possible to provide functions (*obj = ProcessHandler[Mixin](..., onTimeout=functions)*) that will be called if the timeout was reached.
+
+.. code-block:: python
+
+    from mozprocess import processhandler
+
+    def ontimeout():
+        print("REACHED TIMEOUT")
+
+    command = './proc_sleep_echo.sh' # Windows: 'proc_sleep_echo.bat'
+    functions = [ontimeout]
+    p = processhandler.ProcessHandler(command, onTimeout=functions)
+    p.run(timeout=2)
+    p.wait()
+    print("timedOut = %s" % p.timedOut)
+
+By default the process will be killed on timeout but it is possible to prevent this by setting *kill_on_timeout* to *False*.
+
+.. code-block:: python
+
+    p = processhandler.ProcessHandler(command, onTimeout=functions, kill_on_timeout=False)
+    p.run(timeout=2)
+    p.wait()
+    print("timedOut = %s" % p.timedOut)
+
+In this case, no output will be available after the timeout, but the process will still be running.
+
+Waiting
+```````
+
+It is possible to wait until the process exits as already seen with the method *wait()*, or until the end of a timeout if given. Note that in last case the process is still alive after the timeout.
+
+.. code-block:: python
+
+    command = './proc_sleep_echo.sh' # Windows: 'proc_sleep_echo.bat'
+    p = processhandler.ProcessHandler(command)
+    p.run()
+    p.wait(timeout=2)
+    print("timedOut = %s" % p.timedOut)
+    p.wait()
+
+Killing
+```````
+
+You can request to kill the process with the method *kill*. f the parameter "ignore_children" is set to False when the process handler class is initialized, all the process's children will be killed as well.
+
+Except on Windows, you can specify the signal with which to kill method the process (e.g.: *kill(signal.SIGKILL)*).
+
+.. code-block:: python
+
+    import time
+    from mozprocess import processhandler
+
+    command = './proc_sleep_echo.sh' # Windows: 'proc_sleep_echo.bat'
+    p = processhandler.ProcessHandler(command)
+    p.run()
+    time.sleep(2)
+    p.kill()
+
+End of execution
+````````````````
+
+You can provide a function or a list of functions to call at the end of the process using the initialization parameter *onFinish*.
+
+.. code-block:: python
+
+    from mozprocess import processhandler
+
+    def finish():
+        print("Finished!!")
+
+    command = './proc_sleep_echo.sh' # Windows: 'proc_sleep_echo.bat'
+
+    p = processhandler.ProcessHandler(command, onFinish=finish)
+    p.run()
+    p.wait()
+
+Child management
+----------------
+
+Consider the following scripts:
+
+**proc_child.sh**:
+
+.. code-block:: sh
+
+    #!/bin/sh
+    for i in a b c d e
+    do
+        echo $i
+        sleep 1
+    done
+
+**proc_parent.sh**:
+
+.. code-block:: sh
+
+    #!/bin/sh
+    ./proc_child.sh
+    for i in 1 2 3 4 5
+    do
+        echo $i
+        sleep 1
+    done
+
+For windows users consider:
+
+**proc_child.bat**:
+
+.. code-block:: bat
+
+    @echo off
+    FOR %%A IN (a b c d e) DO (
+        ECHO %%A
+        REM TIMEOUT /T 1 /NOBREAK
+        PING -n 2 127.0.0.1 > NUL
+    )
+
+**proc_parent.bat**:
+
+.. code-block:: bat
+
+    @echo off
+    call proc_child.bat
+    FOR %%A IN (1 2 3 4 5) DO (
+        ECHO %%A
+        REM TIMEOUT /T 1 /NOBREAK
+        PING -n 2 127.0.0.1 > NUL
+    )
+
+For processes that launch other processes, mozprocess allows you to get child running status, wait for child termination, and kill children.
+
+Ignoring children
+`````````````````
+
+By default the *ignore_children* option is False. In that case, killing the main process will kill all its children at the same time.
+
+.. code-block:: python
+
+    import time
+    from mozprocess import processhandler
+
+    def finish():
+        print("Finished")
+
+    command = './proc_parent.sh'
+    p = processhandler.ProcessHandler(command, ignore_children=False, onFinish=finish)
+    p.run()
+    time.sleep(2)
+    print("kill")
+    p.kill()
+
+If *ignore_children* is set to *True*, killing will apply only to the main process that will wait children end of execution before stopping (join).
+
+.. code-block:: python
+
+    import time
+    from mozprocess import processhandler
+
+    def finish():
+        print("Finished")
+
+    command = './proc_parent.sh'
+    p = processhandler.ProcessHandler(command, ignore_children=True, onFinish=finish)
+    p.run()
+    time.sleep(2)
+    print("kill")
+    p.kill()
+
+API Documentation
+-----------------
+
+.. module:: mozprocess
+.. autoclass:: ProcessHandlerMixin
+   :members: __init__, timedOut, commandline, run, kill, processOutputLine, onTimeout, onFinish, wait
+.. autoclass:: ProcessHandler
+   :members:
diff --git a/testing/mozbase/docs/mozprofile.rst b/testing/mozbase/docs/mozprofile.rst
new file mode 100644
index 0000000000..d5b6e351b9
--- /dev/null
+++ b/testing/mozbase/docs/mozprofile.rst
@@ -0,0 +1,94 @@
+:mod:`mozprofile` --- Create and modify Mozilla application profiles
+====================================================================
+
+Mozprofile_ is a python tool for creating and managing profiles for Mozilla's
+applications (Firefox, Thunderbird, etc.). In addition to creating profiles,
+mozprofile can install addons_ and set preferences. Mozprofile can be utilized
+from the command line or as an API.
+
+The preferred way of setting up profile data (addons, permissions, preferences
+etc) is by passing them to the profile_ constructor.
+
+Addons
+------
+
+.. automodule:: mozprofile.addons
+   :members:
+
+Addons may be installed individually or from a manifest.
+
+Example::
+
+	from mozprofile import FirefoxProfile
+	
+	# create new profile to pass to mozmill/mozrunner
+	profile = FirefoxProfile(addons=["adblock.xpi"])
+
+Command Line Interface
+----------------------
+
+.. automodule:: mozprofile.cli
+   :members:
+
+The profile to be operated on may be specified with the ``--profile``
+switch. If a profile is not specified, one will be created in a
+temporary directory which will be echoed to the terminal::
+
+    (mozmill)> mozprofile
+    /tmp/tmp4q1iEU.mozrunner
+    (mozmill)> ls /tmp/tmp4q1iEU.mozrunner
+    user.js
+
+To run mozprofile from the command line enter:
+``mozprofile --help`` for a list of options.
+
+Permissions
+-----------
+
+.. automodule:: mozprofile.permissions
+   :members:
+
+You can set permissions by creating a ``ServerLocations`` object that you pass
+to the ``Profile`` constructor. Hosts can be added to it with
+``add_host(host, port)``. ``port`` can be 0.
+
+Preferences
+-----------
+
+.. automodule:: mozprofile.prefs
+   :members:
+
+Preferences can be set in several ways:
+
+- using the API: You can make a dictionary with the preferences and pass it to
+  the ``Profile`` constructor. You can also add more preferences with the
+  ``Profile.set_preferences`` method.
+- using a JSON blob file: ``mozprofile --preferences myprefs.json``
+- using a ``.ini`` file: ``mozprofile --preferences myprefs.ini``
+- via the command line: ``mozprofile --pref key:value --pref key:value [...]``
+
+When setting preferences from  an ``.ini`` file or the ``--pref`` switch,
+the value will be interpolated as an integer or a boolean
+(``true``/``false``) if possible.
+
+Profile
+--------------------
+
+.. automodule:: mozprofile.profile
+   :members:
+
+Resources
+-----------
+Other Mozilla programs offer additional and overlapping functionality
+for profiles.  There is also substantive documentation on profiles and
+their management.
+
+- profile documentation_
+
+
+.. _Mozprofile: https://hg.mozilla.org/mozilla-central/file/tip/testing/mozbase/mozprofile
+.. _addons: https://developer.mozilla.org/en/addons
+.. _mozprofile.profile: https://hg.mozilla.org/mozilla-central/file/tip/testing/mozbase/mozprofile/mozprofile/profile.py
+.. _AddonManager: https://hg.mozilla.org/mozilla-central/file/tip/testing/mozbase/mozprofile/mozprofile/addons.py
+.. _here: https://hg.mozilla.org/mozilla-central/file/tip/testing/mozbase/mozprofile/mozprofile/permissions.py
+.. _documentation: http://support.mozilla.com/en-US/kb/Profiles
diff --git a/testing/mozbase/docs/mozproxy.rst b/testing/mozbase/docs/mozproxy.rst
new file mode 100644
index 0000000000..f6863d7e22
--- /dev/null
+++ b/testing/mozbase/docs/mozproxy.rst
@@ -0,0 +1,46 @@
+:mod:`mozproxy` --- Provides an HTTP proxy
+==========================================
+
+Mozproxy let you launch an HTTP proxy when we need to run tests against
+third-part websites in a reliable and reproducible way.
+
+Mozproxy provides an interface to a proxy software, and the currently
+supported backend is **mitmproxy** for Desktop and Android.
+
+Mozproxy is used by Raptor to run performance test without having to interact
+with the real web site.
+
+Mozproxy provide a function that returns a playback class. The usage pattern is
+::
+
+   from mozproxy import get_playback
+
+   config = {'playback_tool': 'mitmproxy'}
+   pb = get_playback(config)
+   pb.start()
+   try:
+     # do your test
+   finally:
+     pb.stop()
+
+**config** is a dict with the following options:
+
+- **playback_tool**: name of the backend. can be "mitmproxy", "mitmproxy-android"
+- **playback_version**: playback tool version
+- **playback_files**: playback recording path/manifest/URL
+- **binary**: path of the browser binary
+- **obj_path**: build dir
+- **platform**: platform name (provided by mozinfo.os)
+- **run_local**: if True, the test is running locally.
+- **app**: tested app. Can be "firefox",  "geckoview", "refbrow", "fenix" or  "firefox"
+- **host**: hostname for the policies.json file
+- **local_profile_dir**: profile dir
+
+
+Supported environment variables:
+
+- **MOZPROXY_DIR**: directory used by mozproxy for all data files, set by mozproxy
+- **MOZ_UPLOAD_DIR**: upload directory path
+- **GECKO_HEAD_REPOSITORY**: used to find the certutils binary path from the CI
+- **GECKO_HEAD_REV**: used to find the certutils binary path from the CI
+- **HOSTUTILS_MANIFEST_PATH**: used to find the certutils binary path from the CI
diff --git a/testing/mozbase/docs/mozrunner.rst b/testing/mozbase/docs/mozrunner.rst
new file mode 100644
index 0000000000..5020e76cbb
--- /dev/null
+++ b/testing/mozbase/docs/mozrunner.rst
@@ -0,0 +1,183 @@
+:mod:`mozrunner` --- Manage remote and local gecko processes
+============================================================
+
+Mozrunner provides an API to manage a gecko-based application with an
+arbitrary configuration profile. It currently supports local desktop
+binaries such as Firefox and Thunderbird, as well as Firefox OS on
+mobile devices and emulators.
+
+
+Basic usage
+-----------
+
+The simplest way to use mozrunner, is to instantiate a runner, start it
+and then wait for it to finish:
+
+.. code-block:: python
+
+    from mozrunner import FirefoxRunner
+    binary = 'path/to/firefox/binary'
+    runner = FirefoxRunner(binary=binary)
+    runner.start()
+    runner.wait()
+
+This automatically creates and uses a default mozprofile object. If you
+wish to use a specialized or pre-existing profile, you can create a
+:doc:`mozprofile <mozprofile>` object and pass it in:
+
+.. code-block:: python
+
+    from mozprofile import FirefoxProfile
+    from mozrunner import FirefoxRunner
+    import os
+
+    binary = 'path/to/firefox/binary'
+    profile_path = 'path/to/profile'
+    if os.path.exists(profile_path):
+        profile = FirefoxProfile.clone(path_from=profile_path)
+    else:
+        profile = FirefoxProfile(profile=profile_path)
+    runner = FirefoxRunner(binary=binary, profile=profile)
+    runner.start()
+    runner.wait()
+
+
+Handling output
+---------------
+
+By default, mozrunner dumps the output of the gecko process to standard output.
+It is possible to add arbitrary output handlers by passing them in via the
+`process_args` argument. Be careful, passing in a handler overrides the default
+behaviour. So if you want to use a handler in addition to dumping to stdout, you
+need to specify that explicitly. For example:
+
+.. code-block:: python
+
+    from mozrunner import FirefoxRunner
+
+    def handle_output_line(line):
+        do_something(line)
+
+    binary = 'path/to/firefox/binary'
+    process_args = { 'stream': sys.stdout,
+                     'processOutputLine': [handle_output_line] }
+    runner = FirefoxRunner(binary=binary, process_args=process_args)
+
+Mozrunner uses :doc:`mozprocess <mozprocess>` to manage the underlying gecko
+process and handle output. See the :doc:`mozprocess documentation <mozprocess>`
+for all available arguments accepted by `process_args`.
+
+
+Handling timeouts
+-----------------
+
+Sometimes gecko can hang, or maybe it is just taking too long. To handle this case you
+may want to set a timeout. Mozrunner has two kinds of timeouts, the
+traditional `timeout`, and the `outputTimeout`. These get passed into the
+`runner.start()` method. Setting `timeout` will cause gecko to be killed after
+the specified number of seconds, no matter what. Setting `outputTimeout` will cause
+gecko to be killed after the specified number of seconds with no output. In both
+cases the process handler's `onTimeout` callbacks will be triggered.
+
+.. code-block:: python
+
+    from mozrunner import FirefoxRunner
+
+    def on_timeout():
+        print('timed out after 10 seconds with no output!')
+
+    binary = 'path/to/firefox/binary'
+    process_args = { 'onTimeout': on_timeout }
+    runner = FirefoxRunner(binary=binary, process_args=process_args)
+    runner.start(outputTimeout=10)
+    runner.wait()
+
+The `runner.wait()` method also accepts a timeout argument. But unlike the arguments
+to `runner.start()`, this one simply returns from the wait call and does not kill the
+gecko process.
+
+.. code-block:: python
+
+    runner.start(timeout=100)
+
+    waiting = 0
+    while runner.wait(timeout=1) is None:
+        waiting += 1
+        print("Been waiting for %d seconds so far.." % waiting)
+    assert waiting <= 100
+
+
+Using a device runner
+---------------------
+
+The previous examples used a GeckoRuntimeRunner. If you want to control a
+gecko process on a remote device, you need to use a DeviceRunner. The api is
+nearly identical except you don't pass in a binary, instead you create a device
+object. For example to run Firefox for Android on the emulator, you might do:
+
+.. code-block:: python
+
+    from mozrunner import FennecEmulatorRunner
+
+    avd_home = 'path/to/avd'
+    runner = FennecEmulatorRunner(app='org.mozilla.fennec', avd_home=avd_home)
+    runner.start()
+    runner.wait()
+
+Device runners have a `device` object. Remember that the gecko process runs on
+the device. In the case of the emulator, it is possible to start the
+device independently of the gecko process.
+
+.. code-block:: python
+
+    runner.device.start() # launches the emulator
+    runner.start()        # stops the gecko process (if started), installs the profile, (re)starts the gecko process
+
+
+Runner API Documentation
+------------------------
+
+Application Runners
+~~~~~~~~~~~~~~~~~~~
+.. automodule:: mozrunner.runners
+   :members:
+
+BaseRunner
+~~~~~~~~~~
+.. autoclass:: mozrunner.base.BaseRunner
+   :members:
+
+GeckoRuntimeRunner
+~~~~~~~~~~~~~~~~~~
+.. autoclass:: mozrunner.base.GeckoRuntimeRunner
+   :show-inheritance:
+   :members:
+
+BlinkRuntimeRunner
+~~~~~~~~~~~~~~~~~~
+.. autoclass:: mozrunner.base.BlinkRuntimeRunner
+   :show-inheritance:
+   :members:
+
+DeviceRunner
+~~~~~~~~~~~~
+.. autoclass:: mozrunner.base.DeviceRunner
+   :show-inheritance:
+   :members:
+
+Device API Documentation
+------------------------
+
+Generally using the device classes directly shouldn't be required, but in some
+cases it may be desirable.
+
+Device
+~~~~~~
+.. autoclass:: mozrunner.devices.Device
+   :members:
+
+EmulatorAVD
+~~~~~~~~~~~
+.. autoclass:: mozrunner.devices.EmulatorAVD
+   :show-inheritance:
+   :members:
diff --git a/testing/mozbase/docs/mozversion.rst b/testing/mozbase/docs/mozversion.rst
new file mode 100644
index 0000000000..ca2be48c1f
--- /dev/null
+++ b/testing/mozbase/docs/mozversion.rst
@@ -0,0 +1,70 @@
+:mod:`mozversion` --- Get application information
+=================================================
+
+`mozversion <https://hg.mozilla.org/mozilla-central/file/tip/testing/mozbase/mozversion>`_
+provides version information such as the application name and the changesets
+that it has been built from. This is commonly used in reporting or for
+conditional logic based on the application under test.
+
+API Usage
+---------
+
+.. automodule:: mozversion
+    :members: get_version
+
+Examples
+````````
+
+Firefox::
+
+    import mozversion
+
+    version = mozversion.get_version(binary='/path/to/firefox')
+    for (key, value) in sorted(version.items()):
+        if value:
+            print '%s: %s' % (key, value)
+
+Firefox for Android::
+
+    version = mozversion.get_version(binary='path/to/firefox.apk')
+    print version['application_changeset'] # gets hg revision of build
+
+Command Line Usage
+------------------
+
+mozversion comes with a command line program, ``mozversion`` which may be used to
+get version information from an application.
+
+Usage::
+
+    mozversion [options]
+
+Options
+```````
+
+---binary
+'''''''''
+
+This is the path to the target application binary or .apk. If this is omitted
+then the current directory is checked for the existence of an
+application.ini file. If not found, then it is assumed the target
+application is a remote Firefox OS instance.
+
+Examples
+````````
+
+Firefox::
+
+    $ mozversion --binary=/path/to/firefox-bin
+    application_buildid: 20131205075310
+    application_changeset: 39faf812aaec
+    application_name: Firefox
+    application_repository: http://hg.mozilla.org/releases/mozilla-release
+    application_version: 26.0
+    platform_buildid: 20131205075310
+    platform_changeset: 39faf812aaec
+    platform_repository: http://hg.mozilla.org/releases/mozilla-release
+
+Firefox for Android::
+
+    $ mozversion --binary=/path/to/firefox.apk
diff --git a/testing/mozbase/docs/requirements.txt b/testing/mozbase/docs/requirements.txt
new file mode 100644
index 0000000000..53dd4ca675
--- /dev/null
+++ b/testing/mozbase/docs/requirements.txt
@@ -0,0 +1 @@
+marionette_client
diff --git a/testing/mozbase/docs/servingcontent.rst b/testing/mozbase/docs/servingcontent.rst
new file mode 100644
index 0000000000..b1960d9447
--- /dev/null
+++ b/testing/mozbase/docs/servingcontent.rst
@@ -0,0 +1,11 @@
+Handling content for the browser
+================================
+
+It's often necessary to handle data for the browser. This can be accomplished
+by using a local webserver or by setting up a proxy.
+
+.. toctree::
+   :maxdepth: 2
+
+   mozhttpd
+   mozproxy
diff --git a/testing/mozbase/docs/setuprunning.rst b/testing/mozbase/docs/setuprunning.rst
new file mode 100644
index 0000000000..30845a5c7a
--- /dev/null
+++ b/testing/mozbase/docs/setuprunning.rst
@@ -0,0 +1,20 @@
+Set up and running
+------------------
+
+Activities under this domain include installing the software, creating
+a profile (a set of configuration settings), running a program in a
+controlled environment such that it can be shut down safely, and
+correctly handling the case where the system crashes.
+
+.. toctree::
+   :maxdepth: 2
+
+   mozfile
+   mozgeckoprofiler
+   mozinstall
+   mozpower
+   mozprofile
+   mozprocess
+   mozrunner
+   mozcrash
+   mozdebug