MozillaWiki - User contributions [en]

Webdev/GetInvolved/developer.mozilla.org

2017-10-26T06:45:26Z

Xfq: /* Getting Started */ Github -> GitHub

= Get Involved: developer.mozilla.org (MDN) =

== Description ==
[[image:MDN-home-2017.png|frame|left]]
The [https://developer.mozilla.org MDN web docs] is Mozilla's technical resource for web developers - containing documentation for open web technologies.
<div style="clear: both;"></div>

== Getting Started ==
We use Docker for development and deployment. Docker works reasonable well for backend development on a macOS or Linux environment. There are additional steps required for front-end development. No staff developers use Windows, and you will need previous Docker experience on Windows to get a development environment working.

Staff developers are currently focused on tuning MDN for AWS and reducing existing technical debt. We aren't currently curating a list of good first bugs. We don't expect this to change before January 2018. We're not aware of other Mozilla projects that are in a better position for new contributors.

Here's how to contribute to Kuma:

* Fork us on [https://github.com/mozilla/kuma GitHub]
* [https://github.com/mozilla/kuma/blob/master/CONTRIBUTING.md Read our contribution guidelines]
* [https://kuma.readthedocs.io/en/latest/installation.html Install locally]
* Check out the mentored bugs or contact a developer below

== Contacts ==
* Who:
** [https://github.com/jwhitlock John Whitlock] [https://twitter.com/jwhitlock @jwhitlock] (jwhitlock)
** [http://stephaniehobson.ca Stephanie Hobson] [https://twitter.com/stephaniehobson @stephaniehobson ] (stephaniehobson)
* IRC: [irc://irc.mozilla.org/#mdndev #mdndev]

== Mentored Bugs ==
These bugs are good for your first contribution to MDN code. Each bug has a mentor assigned who can help you get started.
<bugzilla>
{
"product": "Mozilla Developer Network",
"f1": "bug_mentor",
"o1": "isnotempty",
"resolution": "---",
"include_fields": "id, summary, whiteboard, assigned_to"
}
</bugzilla>

== PatchWelcome Bugs ==
These bugs are good for more advanced contributions to MDN code that will make a big impact on the site. The bug may or may not have a mentor, and it may take more work than a simple mentored bug.
<bugzilla>
{
"product": "Mozilla Developer Network",
"whiteboard": "patchwelcome",
"resolution": "---",
"include_fields": "id, summary, whiteboard, assigned_to"
}
</bugzilla>

Webdev/GetInvolved/mozilla.org

2017-10-04T13:01:35Z

Xfq: Some editorial fixes

= Get Involved: Mozilla.org =

== Overview ==

Mozilla.org is the main web property for the Mozilla project and Firefox products. The site averages 193 millions users every month, where they can download Firefox, learn about the Mozilla mission, get involved in the Mozilla Community and more.

<div style="clear:both"></div>

== Getting Started ==
Interested in contributing code to mozilla.org? Know HTML, CSS, JS or Python? You can view mentored [[#Mentored_Bugs | bugs below]].

Once you find a bug that interests you, register for a [https://bugzilla.mozilla.org/ Bugzilla] account and comment in the bug that you'd like to work on it. You can also contact the mentor by using the email found in the mentor field.

If you would like to report a Firefox bug, please visit the [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines MDN Bug writing guidelines page].

If interested in testing Firefox, please visit the [https://developer.mozilla.org/en-US/docs/Mozilla/QA Mozilla QA homepage on MDN].

== Resources ==

Everything you need to get up to speed on our development environment and workflow.

* Fork us on [https://github.com/mozilla/bedrock/ GitHub]
* [http://bedrock.readthedocs.org/en/latest/install.html Install locally]
* [http://bedrock.readthedocs.org/en/latest/index.html Docs]
* [https://docs.google.com/document/d/1VpPhrek3hc1OlDMvPQoBo1PNlBWxpc_0ZhFmKfY3PUM/edit#heading=h.wdguoe1lde68 Best Practices for building for mozilla.org]

== Contacts ==
* Who:
** Paul McLanahan (pmac) - developer
** Alex Gibson (agibson) - developer
** Craig Cook (craigcook) - developer
** Josh Mize (jgmize) - developer
** Schalk Neethling (espressive) - developer
** Jon Petto (jpetto) - developer
** Mike Alexis (malexis) - manager
** Benjamin Sternthal (bensternthal) - manager
* IRC: [irc://irc.mozilla.org/www #www]
* mozilla.org on [https://wiki.mozilla.org/Mozilla.org Mozilla Wiki]
* mozilla.org on [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=OPEN+product%3Awww.mozilla.org Bugzilla]
* mozilla.org [https://tree.taiga.io/project/malexis-mozillaorg-durable-team/backlog public Taiga (Scrum) product backlog and sprint task boards]

== Mentored Bugs ==
<bugzilla>
{
"product": "www.mozilla.org",
"whiteboard": "[good first bug]",
"f1": "bug_mentor",
"status": ["NEW", "OPEN", "REOPENED"]
}
</bugzilla>

Webdev/GetInvolved/developer.mozilla.org

2017-05-15T06:43:38Z

Xfq: /* Description */ HTTP -> HTTPS

= Get Involved: developer.mozilla.org (MDN) =

== Description ==
[[image:Mdn-home.png|frame|left]]
The [https://developer.mozilla.org Mozilla Developer Network] is our technical resource for developers - including documentation and demo's for Mozilla and open web technologies.
<div style="clear: both;"></div>

== Getting Started ==
Note: As of July 2016, we are starting the long process of switching from a Vagrant / Virtualbox development environment to a Docker development and deployment environment. There are many issues and bad experiences with the Vagrant environment, and, since it will soon be retired, those will probably not be fixed. During this transition, which may take the rest of 2016, it will be more difficult than we'd like to contribute code to MDN.

Some other projects that are in a better position for new developer volunteers:
* [https://github.com/mozilla/addons-server/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+bug%22 Add-ons Server]
* [https://github.com/mozilla/testpilot/labels/good-first-bug TestPilot]

Here's how to contribute to Kuma:

* Fork us on [https://github.com/mozilla/kuma Github]
* [https://github.com/mozilla/kuma/blob/master/CONTRIBUTING.md Read our contribution guidelines]
* [https://kuma.readthedocs.io/en/latest/installation.html Install locally]
* Check out the mentored bugs or contact a developer below

== Contacts ==
* Who:
** [https://github.com/jwhitlock John Whitlock] [https://twitter.com/jwhitlock @jwhitlock] (jwhitlock)
** [http://stephaniehobson.ca Stephanie Hobson] [https://twitter.com/stephaniehobson @stephaniehobson ] (stephaniehobson)
* IRC: [irc://irc.mozilla.org/#mdndev #mdndev]

== Mentored Bugs ==
These bugs are good for your first contribution to MDN code. Each bug has a mentor assigned who can help you get started.
<bugzilla>
{
"product": "Mozilla Developer Network",
"f1": "bug_mentor",
"o1": "isnotempty",
"resolution": "---",
"include_fields": "id, summary, whiteboard, assigned_to"
}
</bugzilla>

== PatchWelcome Bugs ==
These bugs are good for more advanced contributions to MDN code that will make a big impact on the site. The bug may or may not have a mentor, and it may take more work than a simple mentored bug.
<bugzilla>
{
"product": "Mozilla Developer Network",
"whiteboard": "patchwelcome",
"resolution": "---",
"include_fields": "id, summary, whiteboard, assigned_to"
}
</bugzilla>

Webdev/GetInvolved

2016-11-10T01:38:17Z

Xfq: badges.mozilla.org is deprecated.

Get involved with making Mozilla's web sites even better. This page lists contribution opportunities that you're welcome to work on.

Most of the code on our sites is HTML, CSS, JavaScript and Django (Python) and you can read about how we do web development in the [http://mozweb.readthedocs.org Webdev Bootcamp].

If you have questions or are unsure how you can help, just ask on the [https://groups.google.com/forum/?fromgroups#!forum/mozilla.dev.webdev webdev forum] (to sign up to the forum as a mailing list, go to [https://lists.mozilla.org/listinfo/dev-webdev lists.mozilla.org/listinfo/dev-webdev]) or [irc://irc.mozilla.org#webdev IRC in #webdev] or talk to [https://twitter.com/potch @potch], [https://twitter.com/groovecoder @groovecoder] or [https://twitter.com/r1cky @r1cky] on Twitter.

{{FeaturedProject
|icon=firefox-100.jpg
|pagelocation=Webdev/GetInvolved/mozilla.org
|pagetitle=Featured Project: Mozilla.org
|description=Mozilla.org is the main web property for Mozilla products. [[Webdev/GetInvolved/mozilla.org#Mentored_Bugs|View List Of Mentored Tasks]] and [[Webdev/GetInvolved/mozilla.org|Learn More]]
}}

= Website Projects =
=== [[Webdev/GetInvolved/mozilla.org | www.mozilla.org]] ===
Having retired the Mozilla.com domain, Mozilla.org is now the main web property for Mozilla products and Engagement. Firefox, Thunderbird, Apps, B2G, Identity and Privacy, plus Press Center, Get Involved and others live under this domain.

* [[Webdev/GetInvolved/mozilla.org | Find out more about how to get involved with www.mozilla.org]]

=== [[Webdev/GetInvolved/addons.mozilla.org | addons.mozilla.org (AMO)]] ===
The [https://addons.mozilla.org Firefox Add-ons site] is a gallery of available customizations for the Firefox Web Browser. This is our highest trafficked website (20K+ hits per second) and uses technology like Memcached, Elasticsearch, RabbitMQ and Celery, and more.

* [[Webdev/GetInvolved/addons.mozilla.org|Find out more about how to get involved with addons.mozilla.org (AMO)]]

=== [http://marketplace.readthedocs.org/en/latest/topics/contributing.html Firefox Marketplace / marketplace.firefox.com] ===
[https://marketplace.firefox.com Firefox Marketplace] has an API built on Django and several frontends using JavaScript. Some of these frontends run on websites and some are pre-loaded onto devices, providing a rich portal for users to be able to buy and sell open web apps on their desktop and mobile devices.

*[http://marketplace.readthedocs.org/en/latest/topics/contributing.html Find out more about how to get involved with Firefox Marketplace]

=== [[Webdev/GetInvolved/air.mozilla.org | air.mozilla.org]] ===
[https://air.mozilla.org Air Mozilla] is the Internet multimedia presence of Mozilla, with live and pre-recorded shows, interviews, news snippets, tutorial videos, and features about the Mozilla community.

* [[Webdev/GetInvolved/air.mozilla.org | Find out more about how to get involved with air.mozilla.org]]

=== [[Webdev/GetInvolved/developer.mozilla.org | developer.mozilla.org (MDN)]] ===
The [http://developer.mozilla.org Mozilla Developer Network] is our technical resource for developers - including documentation and demos for Mozilla and open web technologies.

* [[Webdev/GetInvolved/developer.mozilla.org | Find out more about how to get involved with developer.mozilla.org (MDN)]]

See also: [https://github.com/groovecoder/wp-promote-mdn/ Promote MDN WordPress plugin]

=== [[Webdev/GetInvolved/crash-stats.mozilla.org | crash-stats.mozilla.org (Socorro) ]] ===
Socorro is a server to accept and process Breakpad crash reports from Firefox, Thunderbird, etc.

* [[Webdev/GetInvolved/crash-stats.mozilla.org | Find out more about how to get involved with crash-stats.mozilla.org (Socorro) ]]

=== [[Webdev/GetInvolved/mozillians.org | mozillians.org (Mozillians)]] ===
This is a great first project to get involved! [http://mozillians.org/ Mozillians] is our community directory for core Mozilla volunteers and staff. It's a tool used by everyone involved with Mozilla, and it's the primary way that Mozillians can find each other. There are both front-end and back-end development opportunities, and we have mentors from the team to guide you through your first contributions.

* [[Webdev/GetInvolved/mozillians.org | Find out more about how to get involved with mozillians.org]]

=== [[Webdev/GetInvolved/reps.mozilla.org |reps.mozilla.org (ReMo)]] ===
The [https://reps.mozilla.org/ Mozilla Reps site] is where Mozilla Reps report their activities and share the events they run. There are both front-end and back-end development opportunities, and we have mentors to help you with your first contributions.

* [[Webdev/GetInvolved/reps.mozilla.org |Find out more about how to get involved with reps.mozilla.org]]

=== [[Webdev/GetInvolved/input.mozilla.org | input.mozilla.org ]] ===
[https://input.mozilla.org/ Firefox Input] is the user feedback system.

* [[Webdev/GetInvolved/input.mozilla.org | Find out more about how to get involved with input.mozilla.org ]]

=== [[Webdev/GetInvolved/careers.mozilla.org | careers.mozilla.org ]] ===
[https://careers.mozilla.org/ Careers] is the Mozilla jobs listings system.

* [[Webdev/GetInvolved/careers.mozilla.org | Find out more about how to get involved with careers.mozilla.org ]]

=== [[Webdev/GetInvolved/location.services.mozilla.com | location.services.mozilla.com ]] ===
[https://location.services.mozilla.com/ MLS] is an open service which lets devices determine their location based on network infrastructure like WiFi access points and cell towers.

* [[Webdev/GetInvolved/location.services.mozilla.com | Find out more about how to get involved with location.services.mozilla.com ]]

=== [http://dxr.mozilla.org dxr.mozilla.org] ===
DXR is Mozilla's code search and navigation tool, aimed at making sense of large projects like Firefox. It supports full-text and regex searches as well as structural queries like "Find all the callers of this function." Behind the scenes, it uses trigram indices, the re2 library, and structural data collected by a custom compiler plugin. A great project for folks interested in parsers or search.

* [[DXR | Get started here.]]

=== [[Webdev/GetInvolved/PluginCheck | PluginCheck]] ===
Most user know Plugin Check from pointing their browsers to [https://mozilla.org/plugincheck mozilla.org/plugincheck] but, there is a lot more to it than a single web page. There are some really interesting and challenging problems to help solve, from QA automation to improving the flow of reporting plugin updates and a whole bunch of JavaScript to be improved.

[[Webdev/GetInvolved/PluginCheck | Find out how you can get involved with PluginCheck]]

=== [[Webdev/GetInvolved/pontoon.mozilla.org |pontoon.mozilla.org]] ===
[https://pontoon.mozilla.org/ Pontoon] is an in-place localization tool. That means it enables localizers to translate web apps and websites right inside an app or website, with context and spatial limitations just in front of them. It is incredible.

* [[Webdev/GetInvolved/pontoon.mozilla.org |Find out more about how to get involved with Pontoon]]

= WordPress =
Mozilla runs a number of WordPress sites, and has developed a number of WordPress plugins.

* [[Webdev/GetInvolved/WordPress | Find out more about how to get involved with WordPress projects]]

= Libraries =

We've got lots of libraries we've written, many of which are looking for help.

=== [[Webdev/GetInvolved/django-browserid |django-browserid]] ===
Django library providing BrowserID/Persona based authentication.

* [[Webdev/GetInvolved/django-browserid |Find out more about how to get involved with django-browserid]]

=== [https://github.com/andymckay/django-paranoia django-paranoia] ===
Django library for warning people about attempted security intrusions.

=== [https://github.com/andymckay/django-statsd django-statsd] ===
Django library for creating metrics using Graphite and Statsd.

= Firefox OS =

If you are interested in HTML, CSS, and JavaScript, we could also use your help building our new [http://www.mozilla.org/firefoxos/ Firefox OS]. Find out more about how to help with that:

* https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Platform/Gaia/Hacking

= Learning Web Development =

If you're interested in learning more about web development and how the web works, you may be interested in our Webmaker project:

* https://webmaker.org/

= Web Technology Demos =

The [https://developer.mozilla.org/demos Mozilla Demo Studio] is a platform for showing the world what you can do with the Web. Not an expert? No problem. Some of the most interesting demos (like [https://developer.cdn.mozilla.net/media/uploads/demos/t/u/tuxie/fa3427d4b07c782f827580b5016550bc/santas-media-queries_1319913515_demo_package/index.html Santa's Media Queries]) are actually pretty simple under the hood. As long as you have a sense of creativity and a passion for making things better, we would love to have you.

User:Xfq

2016-10-31T13:35:11Z

Xfq:

I'm interested in HTML/CSS/JavaScript and web browsers.

DevTools/Hacking

2016-10-10T23:00:45Z

Xfq: https://hg.mozilla.org/mozilla-central/rev/3b90d45a2bbc#l3244.2

Want to work on [[DevTools|Firefox Developer Tools]]? You've come to the right place! If you want more information about contributing, check out our guide for [[DevTools/GetInvolved|getting involved]].

= Building, running, updating and rebuilding =

== First Build ==

Follow the instructions on [https://developer.mozilla.org/En/Simple_Firefox_build how to build Firefox].

(If you want to work with the very latest code, you will need to use:

hg clone http://hg.mozilla.org/integration/mozilla-inbound

Instead of:

hg clone http://hg.mozilla.org/mozilla-central

but for most purposes a mozilla-central clone is fine.)

For your first build, running <code>./mach build</code> should do the trick after you get the source code. If you are going to be building a lot, you may want to set up your [https://developer.mozilla.org/en-US/docs/Configuring_Build_Options .mozconfig file].

== First Run ==

Once you have built Firefox, you can run it with

$ ./mach run

or

$ ./mach run -P development

What is the <code>-P development</code>? It is a flag telling Firefox to use a different [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profile], named "development" (this name can be anything you want). If it does not exist the first time you run it, Firefox will open a popup and you can create a new profile with the name you passed in. If you don't specify a profile, <code>mach</code> will create a temporary profile in the path <code><objdir>/tmp/scratch_user</code>.

Once this command runs, you should see a new Firefox window, called "Nightly".

== Incremental Builds ==

Once you've already built Firefox once, if you want to update with the latest changes from the repo, run:

$ hg pull -u

To build with the latest changes or with your own DevTools changes, you can run:

$ ./mach build faster

which is much faster than your first build or clobber builds and should only take a few seconds. You can run your build the same way you did before:

$ ./mach run -P development

If you happen to change any C++ files (which is pretty rare when working on DevTools), you may need a different command for incremental builds:

$ ./mach build binaries

A full <code>./mach build</code> will work for any type of change, it just takes longer to run than the incremental options above.

Note that whenever you pull the latest changes from <tt>fx-team</tt> into your local repository, you may need to "clobber". A "clobber" is similar to a "<code>make clean</code>". You'll know you need to clobber when you get a big error message telling you to do a clobber build after you tried to do an incremental build. To do a clobber build, enter these commands:

$ ./mach clobber
$ ./mach build

== Artifact builds (or: building faster!) ==

If you are '''not''' going to modify any C/C++ code, you could use artifact builds. This method downloads prebuilt components, and then the build process becomes faster.

Essentially, add the following lines to your .mozconfig file:

# Automatically download and use compiled C++ components:
ac_add_options --enable-artifact-builds

# Write build artifacts to:
mk_add_options MOZ_OBJDIR=./objdir-frontend

And then you can follow the normal build process.

For more information on aspects such as technical limitations, read the [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Artifact_builds Artifact Builds] page.

= Configuring your dev profile =

You will want to make a couple of quick changes to the profile you use when running your version of Firefox.

== Enable remote debugging and the Browser Toolbox ==

Open DevTools, and click the "Toolbox Options" gear in the top left. Make sure the following two options are checked:

* '''Enable browser chrome and add-on debugging toolboxes'''
* '''Enable remote debugging'''

These settings allow you to use the [https://developer.mozilla.org/docs/Tools/Browser_Toolbox browser toolbox] to set breakpoints inside of the DevTools code, inspect the DevTools themselves, and let you run the [https://developer.mozilla.org/en-US/docs/Tools/Scratchpad Scratchpad] in the ''Browser'' environment.

[[Image:DevToolsDeveloperSettings.png|center|600px|Settings for developer tools - "Enable Chrome Debugging" and "Enable Remote Debugging"]]

You might also want to change the following preference in '''<tt>about:config</tt>''' to <code>false</code>:

* '''devtools.debugger.prompt-connection'''

This will get rid of the prompt displayed every time you open the browser toolbox.

== Enabling DevTools Logging ==

Depending on what you are working on, you may want to make some changes to your profile to enable more logging. If you type '''<tt>about:config</tt>''' in the URL bar, click through the warning page, and search for '''<tt>devtools</tt>''' you can see some of them.

Add the global "dump" function to all windows which logs strings to stdout.

'''browser.dom.window.dump.enabled''' = true

Dumps all packets sent over the remote debugging protocol to stdout (requires browser.dom.window.dump.enabled):

'''devtools.debugger.log''' = true

Log every event notification from the EventEmitter class (devtools/shared/event-emitter.js) (requires browser.dom.window.dump.enabled)

'''devtools.dump.emit''' = true

Restart the browser to apply configuration changes.

You may also be interested in the remote protocol inspector add-on: https://github.com/firebug/rdp-inspector/wiki

== Enabling DevTools Assertions ==

Highly recommended for DevTools hackers!

Add this to your '''<tt>.mozconfig</tt>''':

ac_add_options --enable-debug-js-modules

Assert your own invariants like this:

const { assert } = require("devtools/shared/DevToolsUtils");
// ...
assert(1 + 1 === 2, "I really hope this is true...");

When assertions are enabled, assertion failures are fatal, log console warnings, and throw errors.

When assertions are not enabled, the <tt>assert</tt> function is a no-op.

It also enables the "debug" builds of certain third party libraries, such as React.

= Developer Tools Directories Overview =

* '''<tt>devtools/shared</tt>''': Code shared by both the DevTools client (front-end UI) and server. If we are using any third party libraries, or importing external repositories into our tree, those libraries generally live here (eg, <tt>devtools/shared/acorn</tt>), assuming they are used by both client and server.
** '''<tt>devtools/shared/client</tt>''': Code for the DevTools [[Remote Debugging Protocol]] client. (You may wonder why this is not in <tt>devtools/client</tt> below: it's mainly because tests in server also need access to the RDP client.)
** '''<tt>devtools/shared/locales</tt>''': Strings used in either the DevTools server only, or shared with both the client and server
* '''<tt>devtools/server</tt>''': Code for the DevTools [[Remote Debugging Protocol]] server and transport layer.
** '''<tt>devtools/server/actors</tt>''': [[Remote_Debugging_Protocol#Actors RDP Actors]]. Note that if you're modifying the RDP, you may need to worry about [[DevTools/Backwards_Compatibility|backwards compatibilty with older protocol implementations]].
* '''<tt>devtools/client</tt>''': Front end user interfaces for our tools. Should be pretty obvious what is what based on the directory names and each panel we have in our toolbox. This directory is only shipped with desktop Firefox, as opposed to other directories above, which are shipped with all Gecko products (Firefox OS, Firefox for Android, etc.)
** '''<tt>devtools/client/locales</tt>''': Strings used in the DevTools client (front-end UI)
** '''<tt>devtools/client/themes</tt>''': CSS and images used in the DevTools client (front-end UI)

= Various DevTools resource types =

== JavaScript Modules ==

=== Build Configuration ===

JavaScript modules are installed by our build system using <tt>moz.build</tt> files. If you add a new JavaScript module, you'll need to update (or add) one of these files to make the build system aware of your new module. See the example below.

A <tt>moz.build</tt> file must live in the same directory as the files to be installed. Don't list files from a subdirectory in a <tt>moz.build</tt> from a parent directory.

Following these steps ensures that <tt>require()</tt> and <tt>resource://</tt> paths map directly to locations in the source tree, instead of being totally arbitrary.

Example:

* File: <tt>/devtools/server/actors/layout.js</tt>
* In <tt>/devtools/server/actors/moz.build</tt>:

DevToolsModules(
'layout.js'
)

=== <tt>require()</tt> ===

Most DevTools JS code is in the form of CommonJS modules that loaded with <tt>require()</tt>.

To <tt>require()</tt> a file, the module ID is exactly its source tree path.

Example:

* File: <tt>/devtools/server/actors/layout.js</tt>
* Usage (prefer lazy in most cases):
** <tt>loader.lazyRequireGetter(this, "layout", "devtools/server/actors/layout")</tt>
** <tt>require("devtools/server/actors/layout")</tt>

=== <tt>Cu.import()</tt> ===

Some older DevTools JS modules use the Gecko [https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Using "JavaScript code module"] format with the file extension <tt>.jsm</tt>. We are trying to move away from this format, so it's unlikely you would add a new one, but you might need to import an existing one in your code.

These modules are loaded using <tt>Cu.import()</tt>. To <tt>import()</tt> a file, you provide a <tt>resource://</tt> URL, which is exactly the source tree path.

In more detail:

* <tt>/devtools/client/<X></tt>: <tt>resource://devtools/client/<X></tt>
* <tt>/devtools/server/<X></tt>: <tt>resource://devtools/server/<X></tt>
* <tt>/devtools/shared/<X></tt>: <tt>resource://devtools/shared/<X></tt>

Example:

* File: <tt>/devtools/shared/Loader.jsm</tt>
* Usage:
** <tt>Cu.import("resource://devtools/shared/Loader.jsm")</tt>

Example:

* File: <tt>/devtools/client/framework/gDevTools.jsm</tt>
* Usage (prefer lazy in most cases):
** <tt>loader.lazyImporter(this, "gDevTools", "resource://devtools/client/framework/gDevTools.jsm")</tt>
** <tt>Cu.import("resource://devtools/client/framework/gDevTools.jsm")</tt>

== Chrome Content ==

Much of the DevTools front-end / UI is currently loaded using <tt>chrome://</tt> URLs, which allow those files to have privileged access to platform internals.

This is typically used to load XUL, HTML, and JS files in the UI.

Note: "Chrome" here means "browser chrome", as in the UI, and bears no relation to "Chrome" as in the browser. We'd like to move away from this on DevTools and be more like regular web sites, but most tools are using <tt>chrome://</tt> URLs for now.

=== Packaging ===

If you add a new file that should be loaded via a <tt>chrome://</tt> URL, you need to update a manifest file at <tt>/devtools/client/jar.mn</tt> so that it's packaged correctly.

Please ensure that any new files are added so their entire source tree path is part of the URL. To do so, the <tt>jar.mn</tt> entry should look like:

content/<X> (<X>)

where <tt><X></tt> is the path to your file after removing the <tt>/devtools/client/</tt> prefix.

Example:

* File: <tt>/devtools/client/webaudioeditor/models.js</tt>
* Entry: <tt>content/webaudioeditor/models.js (webaudioeditor/models.js)</tt>

=== Usage ===

Chrome content URLs almost match their source tree path, with one difference: the segment <tt>client</tt> is replaced by <tt>content</tt>. This is a requirement of the <tt>chrome://</tt> protocol handler.

Example:

* File: <tt>/devtools/client/webaudioeditor/models.js</tt>
* Usage: <tt>chrome://devtools/content/webaudioeditor/models.js</tt>

For files within a single tool, consider relative URLs. They're shorter!

== Chrome Themes ==

Similar to the chrome content section above, we also use chrome themes (or <tt>skin</tt> URLs) in the DevTools UI. These are typically used to load CSS and images.

=== Packaging ===

If you add a new file that should be loaded via <tt>chrome://</tt> (such as a new CSS file for a tool UI), you need to update a manifest file at <tt>/devtools/client/jar.mn</tt> so that it's packaged correctly.

Please ensure that any new files are added so their entire source tree path is part of the URL. To do so, the <tt>jar.mn</tt> entry should look like:

skin/<X> (themes/<X>)

where <tt><X></tt> is the path to your file after removing the <tt>/devtools/client/themes/</tt> prefix.

Example:

* File: <tt>/devtools/client/themes/images/add.svg</tt>
* Entry: <tt>skin/images/add.svg (themes/images/add.svg)</tt>

=== Usage ===

Chrome theme URLs almost match their source tree path, with one difference: the segment <tt>client/themes</tt> is replaced by <tt>skin</tt>. This is a requirement of the <tt>chrome://</tt> protocol handler.

Example:

* File: <tt>/devtools/client/themes/images/add.svg</tt>
* Usage: <tt>chrome://devtools/skin/images/add.svg</tt>

== Localization (l10n) ==

Similar to the other chrome sections above, we also use <tt>locale</tt> URLs in the DevTools UI to load localized strings. This section applies to <tt>*.dtd</tt> (for use as entities within XUL / XHTML files) and <tt>*.properties</tt> (for use via runtime APIs) files.

We currently have two sets of localized files:

* '''<tt>devtools/client/locales</tt>''': Strings used in the DevTools client (front-end UI)
* '''<tt>devtools/shared/locales</tt>''': Strings used in either the DevTools server only, or shared with both the client and server

=== Packaging ===

If you add a new l10n file (such as a new <tt>*.dtd</tt> or <tt>*.properties</tt> file), there should not be any additional packaging steps to perform, assuming the new file is placed in either of the 2 directories mentioned above. Each one contains a <tt>jar.mn</tt> which uses wildcards to package all files in the directory by default.

=== Usage ===

Locale URLs differ somewhat based on whether they are in <tt>client</tt> or <tt>shared</tt>. While we would have preferred them to match the source tree path, the requirements of the <tt>chrome://</tt> protocol don't make that easy to do.

Example:

* File: <tt>/devtools/client/locales/en-US/debugger.dtd</tt>
* Usage: <tt>chrome://devtools/locale/debugger.dtd</tt>

Example:

* File: <tt>/devtools/shared/locales/en-US/gcli.properties</tt>
* Usage: <tt>chrome://devtools-shared/locale/gcli.properties</tt>

=== Guidelines ===

Localization files should follow a set of guidelines aimed at making it easier for people to translate the labels in these files in many languages.

[https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_content_best_practices Find these guidelines on MDN].

In particular, it's important to write self-explanatory comments for new keys, deleting unused keys, changing the key name when changing the meaning of a string, and more. So make sure you read through these guidelines should you have to modify a localization file in your patch.

= DevTools Automated Tests =

We use three suites of tests:

* '''xpcshell''': Unit-test style of tests. No browser window, just a JavaScript shell. Mostly testing APIs directly.
* '''mochitest-chrome''': Unit-test style of tests, but with a browser window. Mostly testing APIs that interact with the DOM directly.
* '''mochitest-devtools''': Integration style of tests. Fires up a whole browser window with every test and you can test clicking on buttons, etc.

More information about the different types of tests can be found on the [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Automated_testing MDN automated testing page]

== Running DevTools Tests ==

To run all DevTools tests, regardless of suite type:

$ ./mach test devtools/*

The following sections show more specific commands for running only a single suite or single test in a suite.

=== xpcshell Tests ===

To run all of the xpcshell tests:

$ ./mach xpcshell-test --tag devtools

To run a specific xpcshell test:

$ ./mach xpcshell-test devtools/path/to/the/test_you_want_to_run.js

=== Chrome Mochitests ===

To run the whole suite of chrome mochitests for DevTools:

$ ./mach mochitest -f chrome --tag devtools

To run a specific chrome mochitest:

$ ./mach mochitest devtools/path/to/the/test_you_want_to_run.html

=== DevTools Mochitests ===

To run the whole suite of browser mochitests for DevTools (sit back and relax):

$ ./mach mochitest --subsuite devtools --tag devtools

To run a specific tool's suite of browser mochitests:

$ ./mach mochitest devtools/client/<tool>

For example, run all of the debugger browser mochitests:

$ ./mach mochitest devtools/client/debugger

To run a specific DevTools mochitest:

$ ./mach mochitest devtools/client/path/to/the/test_you_want_to_run.js

Note that the mochitests '''must''' have focus while running.

== Writing Tests ==

When working on a patch for DevTools, there's almost never a reason not to add a new test. If you are fixing a bug, you probably should write a new test to prevent this bug from occurring again. If you're implementing a new feature, you probably should write many new tests to cover the various aspects of this new feature.

You should ask yourself:
* Are there enough tests for my patch?
* Are they the right types of tests?

To help with writing nice, maintainable and consistent DevTools mochitests, please follow our [https://wiki.mozilla.org/DevTools/mochitests_coding_standards DevTools mochitests coding guide].

== Debugging Intermittent Test Failures ==

When a test fails sometimes, but not always, it is called an "intermittent". Handling these is complicated enough that we have a [[DevTools/Intermittents|separate page]] with tips on debugging.

= Finding documentation =

If you read through the source code about something you do not know about, you may find documentation here:

* [http://developer.mozilla.org/ Mozilla Developer Network] has a ton of info about XUL elements, HTML, JS, DOM, Web APIs, Gecko-specific APIs, and more.
* [http://dxr.mozilla.org/mozilla-central/source/ DXR] is a source code search engine - search for symbols you want to learn about, eg. nsIDocument.
* There's some technical [https://dxr.mozilla.org/mozilla-central/source/devtools/docs DevTools documentation in the repository] that you should check.
* And other technical documents on [[DevTools#Internal_Technical_Documentation|on this wiki]]

We recommend [https://support.mozilla.org/en-US/kb/how-search-from-address-bar adding a smart keyword search] for DXR and MDN.
If you still have questions, [[DevTools/GetInvolved#Communication|ask us on IRC]] or leave a comment on the Bugzilla ticket.

= Making and Submitting a Patch =

Before you make any changes, read [http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/index.html the documentation on how to use Mozilla's version control].

Before you submit a patch, you should read our [[DevTools/CodingStandards|Coding Standards]] and run [https://wiki.mozilla.org/DevTools/CodingStandards#JS_linting_with_ESLint ESLint] to validate your code changes (to avoid loosing time during code reviews with formatting details for instance). In general, try to be File Consistent. For new files, follow the standards.

Once you have a patch file, add it as an attachment to the Bugzilla ticket you are working on and add the '''feedback?''' or '''review?''' flag depending on if you just want feedback and confirmation you're doing the right thing or if you think the patch is ready to land respectively. Read more about [https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch how to submit a patch and the Bugzilla review cycle here].

You can also take a look at the [[DevTools/Code Review Checklist]] as it contains a list of checks that your reviewer is likely to go over when reviewing your code.

= Coding Standards =

DevTools has some coding standards that your changes should follow:

* [[DevTools/CodingStandards|JavaScript coding standards]]
* [[DevTools/CSSTips|CSS tips]]
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/SVG_Guidelines SVG Best practices] and [https://dxr.mozilla.org/mozilla-central/source/devtools/docs/svgs.md guidelines for creating new DevTools SVGs]

= Potential Pitfalls =

Today there are a few techniques and conventions we use that can be confusing, especially when you first start working with the code base. We hope to improve these with time to make things easier for everyone, but for now this [https://public.etherpad-mozilla.org/p/devtools-intro-pitfalls etherpad] might be a helpful set of notes if you are having trouble. If you find new pitfalls that aren't listed there, feel free to add your own entries, so we know to address them. Also, please come talk to us in #devtools on IRC, as that might be the fastest path to solving the issue.

DevTools/GetInvolved

2016-09-29T07:50:18Z

Xfq: /* Resources */ Update.

This page is the place to learn how to start contributing to the Firefox Developer Tools.

The Firefox Developer Tools are developed by the Mozilla community. We focus on building tools that make life easier for web (and mobile web) developers, addon developers, and Firefox developers. We hope the information on this page will help you become an active member of our community!

If after reading this wiki page, you still aren't sure what you're next steps are, [[#Communication|reach out to us on IRC]].

== Communication ==

* Twitter: [https://twitter.com/FirefoxDevTools @FirefoxDevTools]
* Mailing list: [https://lists.mozilla.org/listinfo/dev-developer-tools dev-developer-tools]
* Blog (shared): [http://hacks.mozilla.org/ Mozilla Hacks]
* [[DevTools|Weekly phone calls]]

On top of that, we make heavy use of IRC chat in our day to day development. If you haven't used IRC before, check out the [[IRC|guide to getting started with IRC]].

We hang out in the '''#devtools''' channel at irc://irc.mozilla.org/devtools

If you have questions about a specific part of the code, here are some good people to ping:

* '''about:debugging''': jdescottes
* '''Animation Inspector''': pbro
* '''Canvas Debugger''': vporof
* '''Console''': bgrins, linclark
* '''Debugger''': ejpbruel, jlongster
* '''Developer Toolbar''': jwalker, mikeratcliffe
* '''DOM''': honza
* '''Framework, toolbox''': bgrins, jryans, honza, jlong
* '''Inspector''': pbro, gl, zer0, tromey
* '''JSON Viewer''': honza
* '''Memory''': fitzgen
* '''Network Monitor''': honza
* '''Performance''': gtatum
* '''Responsive Design''': jryans, gl
* '''Scratchpad''': jdescottes
* '''Style Editor''': gl
* '''Storage Inspector''': mikeratcliffe
* '''UI/UX''': helenvholmes
* '''Web Audio Editor''': jsantell
* '''WebIDE''': jryans, ochameau, janx

== Reporting Bugs and Requesting Features ==

To report a bug/usability papercut/smaller feature/etc, [https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Developer%20Tools file a bug in the Developer Tools component] on Mozilla's Bugzilla.

If you have an idea for a new feature, you can [[#Communication|post it to the mailing list]] where Firefox DevTools team members are available to answer questions and respond to comments.

== Mentored and Good First Bugs ==

The [http://firefox-dev.tools/ firefox-dev.tools] site can help you find good first bugs and/or mentored bugs.

If you want to pick one of these up, feel free to ask for help in attacking the bug right in the bug itself, in [[#Communication|#devtools on irc.mozilla.org, or on the dev-developer-tools mailing list]]!

One more useful link: [https://bugzil.la/comp%3A%22Developer%20Tools%22 all open developer tools bugs] might have other items you'd find interesting to work on.

Don't hesitate to ask to be mentored even on bugs that don't have a mentor assigned yet.

[[Category:New Contributor Landing Page]]

== Hacking ==

If you are ready to get the source code and start working on DevTools, check out our [[DevTools/Hacking|guide to hacking DevTools]].

== Resources ==

Here's a list of resources that you may find useful for hacking on DevTools. Feel free to add more if you find things are missing!

* [https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F How to format patches]
* [http://dxr.mozilla.org/mozilla-central/source/ DXR Code Search]
* [https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/index.html Mercurial for Mozillians]
* [https://developer.mozilla.org/en-US/docs/Developer_Guide/mach mach]
* [http://flailingmonkey.com/bugzilla-tips-hacks-and-etiquette Bugzilla Tips, Hacks and Etiquette]
* [http://blog.margaretleibovic.com/post/36893756730/bugzilla-101 Bugzilla 101]
* [http://www.mozilla.org/hacking/commit-access-policy/ Commit access policy]
* [http://mozillians.org Mozillians Directory]
* [https://wiki.mozilla.org/ReleaseEngineering/TryServer Try Server]
* [https://wiki.mozilla.org/DevTools/Hacking Coding for DevTools]

DevTools/GetInvolved

2016-09-27T01:44:44Z

Xfq: ffdevtools on uservoice is no longer available

This page is the place to learn how to start contributing to the Firefox Developer Tools.

The Firefox Developer Tools are developed by the Mozilla community. We focus on building tools that make life easier for web (and mobile web) developers, addon developers, and Firefox developers. We hope the information on this page will help you become an active member of our community!

If after reading this wiki page, you still aren't sure what you're next steps are, [[#Communication|reach out to us on IRC]].

== Communication ==

* Twitter: [https://twitter.com/FirefoxDevTools @FirefoxDevTools]
* Mailing list: [https://lists.mozilla.org/listinfo/dev-developer-tools dev-developer-tools]
* Blog (shared): [http://hacks.mozilla.org/ Mozilla Hacks]
* [[DevTools|Weekly phone calls]]

On top of that, we make heavy use of IRC chat in our day to day development. If you haven't used IRC before, check out the [[IRC|guide to getting started with IRC]].

We hang out in the '''#devtools''' channel at irc://irc.mozilla.org/devtools

If you have questions about a specific part of the code, here are some good people to ping:

* '''about:debugging''': jdescottes
* '''Animation Inspector''': pbro
* '''Canvas Debugger''': vporof
* '''Console''': bgrins, linclark
* '''Debugger''': ejpbruel, jlongster
* '''Developer Toolbar''': jwalker, mikeratcliffe
* '''DOM''': honza
* '''Framework, toolbox''': bgrins, jryans, honza, jlong
* '''Inspector''': pbro, gl, zer0, tromey
* '''JSON Viewer''': honza
* '''Memory''': fitzgen
* '''Network Monitor''': honza
* '''Performance''': gtatum
* '''Responsive Design''': jryans, gl
* '''Scratchpad''': jdescottes
* '''Style Editor''': gl
* '''Storage Inspector''': mikeratcliffe
* '''UI/UX''': helenvholmes
* '''Web Audio Editor''': jsantell
* '''WebIDE''': jryans, ochameau, janx

== Reporting Bugs and Requesting Features ==

To report a bug/usability papercut/smaller feature/etc, [https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Developer%20Tools file a bug in the Developer Tools component] on Mozilla's Bugzilla.

If you have an idea for a new feature, you can [[#Communication|post it to the mailing list]] where Firefox DevTools team members are available to answer questions and respond to comments.

== Mentored and Good First Bugs ==

The [http://firefox-dev.tools/ firefox-dev.tools] site can help you find good first bugs and/or mentored bugs.

If you want to pick one of these up, feel free to ask for help in attacking the bug right in the bug itself, in [[#Communication|#devtools on irc.mozilla.org, or on the dev-developer-tools mailing list]]!

One more useful link: [https://bugzil.la/comp%3A%22Developer%20Tools%22 all open developer tools bugs] might have other items you'd find interesting to work on.

Don't hesitate to ask to be mentored even on bugs that don't have a mentor assigned yet.

[[Category:New Contributor Landing Page]]

== Hacking ==

If you are ready to get the source code and start working on DevTools, check out our [[DevTools/Hacking|guide to hacking DevTools]].

== Resources ==

Here's a list of resources that you may find useful for hacking on DevTools. Feel free to add more if you find things are missing!

* [https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F How to format patches]
* [http://mxr.mozilla.org/mozilla-central/ MXR Code Search]
* [http://dxr.mozilla.org/mozilla-central/source/ DXR Code Search]
* [https://developer.mozilla.org/en-US/docs/Mercurial_FAQ Mercurial FAQ]
* [https://developer.mozilla.org/en-US/docs/Developer_Guide/mach mach]
* [http://flailingmonkey.com/bugzilla-tips-hacks-and-etiquette Bugzilla Tips, Hacks and Etiquette]
* [http://blog.margaretleibovic.com/post/36893756730/bugzilla-101 Bugzilla 101]
* [http://www.mozilla.org/hacking/commit-access-policy/ Commit access policy]
* [http://mozillians.org Mozillians Directory]
* [https://wiki.mozilla.org/ReleaseEngineering/TryServer Try Server]
* [https://wiki.mozilla.org/DevTools/Hacking Coding for DevTools]

User:Xfq

2015-01-02T01:17:54Z

Xfq:

I'm interested in JavaScript and web engines.

Standards

2014-12-13T02:57:00Z

Xfq: ECMA -> Ecma International

Welcome to Mozilla's standards participation page.

Many at Mozilla participate in the development of open web standards, in a variety of different standards bodies. This is a directory of standards organizations (and sub-orgs like working groups) listing who at Mozilla is working with each. For a technology summary see the [[standards/technologies|technologies]] page.

To encourage better web standards coordination and cross-pollination, the sections below are organized alphabetically by standards body, then alphabetically by working group (if any), then the list of Mozilla folks participating in that working group, optionally listing which particular specifications (or sections thereof) that they edit/author/contribute to.

If you actively directly communicate/participate with a standards body (working group email list, IRC, wiki, and/or f2f meetings), please add yourself (and the specific standards body / working group if any).

If you work in multiple working groups or with multiple standards organizations, list yourself in each, linking to your wiki User page.

Thanks!

— [[User:Tantek|Tantek]]

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

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

== Ecma International ==
* Brendan Eich
* dherman
* Allen Wirfs-Brock (Project Editor)
* Andreas Gal

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

== IETF ==
http://ietf.org/
* ... no lead currently ...
* ISOC Advisory Council Members:
** Adam Roach (:abr)
** Tim Terriberry (:derf)

=== Calsify (iCalendar) ===
* Most calendar related standards, list at: http://www.ietf.org/mail-archive/web/calsify/current/maillist.html

* Philipp Kewisch

Specifications [http://tools.ietf.org/html/rfc5545 rfc5545] [http://tools.ietf.org/html/rfc5546 rfc5546] [http://www.ietf.org/id/draft-kewisch-et-al-icalendar-in-json-01.txt icalendar-in-json] and related.

=== dnsop ===
* lshapiro (Larissa Shapiro)

=== dhcp ===

* lshapiro (Larissa Shapiro)

=== STIR ===
** Eric Rescorla

=== HyBi ===
* HyBi (WebSockets)
** Pat McManus
** Chris Blizzard (emeritus as of 2012-03-16)

=== TLS (SSL) ===
* [[User:Briansmith|Brian Smith]]
* Eric Rescorla

=== VCARDDAV ===
vcarddav group/list at: [http://www.ietf.org/mail-archive/web/vcarddav/current/maillist.html http://www.ietf.org/mail-archive/web/vcarddav/current/maillist.html]
* [[User:Tantek|Tantek Çelik]]
* Philipp Kewisch
Specifications: [[vCard4]] [http://www.ietf.org/id/draft-kewisch-vcard-in-json-00.txt vcard-in-json]

=== Opus ===
* Jean-Marc Valin (:jmspeex)
* Tim Terriberry (:derf)
* Ralph Giles (:rillian)

=== RTCWEB / MMUSIC ===
* Randell Jesup
* Tim Terriberry
* Ralph Giles
* Adam Roach (:abr)
* Eric Rescorla (EKR)
* Maire Reavy 

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

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

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

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

Specifications:
* [http://openwebfoundation.org/legal/agreement/ Open Web Foundation Agreement] (OWFa)

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

=== Advisory Board ===
Elected member to the [http://www.w3.org/wiki/AB W3C Advisory Board].
* [[User:Tantek|Tantek Çelik]] 

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

=== Audio Incubator Group ===
http://www.w3.org/2005/Incubator/audio/
* Alistair MacDonald

=== Audio Working Group ===
* Matthew Gregan

=== Browser Testing and Tools Working Group ===
* David Burns
* Clint Talbert (IRC: ctalbert)

Specifications:
* APIs (application programming interfaces) for use in automated testing of Web applications
* APIs for use in troubleshooting and debugging of Web applications

=== Core Mobile Web Platform Community Group ===
http://www.w3.org/community/coremob/
* [[User:Brendan|Brendan Eich]]
* Jonas Sicking
* Ragavan Srinivasan
* Jet Villegas

=== CSS (Cascading Style Sheets) Working Group ===
http://w3.org/Style/CSS/
* irc://irc.w3.org:6665/css
* email: http://lists.w3.org/Archives/Public/www-style/
Working group members related to Mozilla (also on w3c-css-wg)
* [[User:Dbaron|David Baron]]
* [[User:Tantek|Tantek Çelik]]
* John Daggett
* [[User:Fantasai|fantasai]]
* Aryeh Gregor
* Masayuki Nakano
* [[User:Jetvillegas|Jet Villegas]]

Additional www-style list participants related to Mozilla (anyone is welcome to join)
* Robert O'Callahan
* Henri Sivonen
* Boris Zbarsky
* Daniel Holbert
* ...

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

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

=== Federated Social Web Community Group ===
* http://www.w3.org/community/fedsocweb/
Participants:
* David Ascher
* [[User:Tantek|Tantek Çelik]]

was previously: Federated Social Web Incubator Group

=== Games Community Group ===
http://www.w3.org/community/games/
* Rob Hawkes
* Alan Kligman
* Dan Mosedale
* Bobby Richter

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

=== HTML Working Group ===
HTML (HyperText Markup Language) Working Group (WG), sometimes listed as "HTML5 WG"
http://www.w3.org/html/wg/
* [[User:Tantek|Tantek Çelik]]
* [[User:Mounir.lamouri|Mounir Lamouri]]
* Jonas Sicking
* Henri Sivonen
* [[User:Jetvillegas|Jet Villegas]]
* ...

Specifications: [[HTML5]]

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

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

=== Internationalization Working Group ===
http://w3.org/International/
* [[User:Fantasai|fantasai]]

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

=== Near Field Communications Working Group ===
W3C [http://www.w3.org/2012/nfc/ Near Field Communications (NFC) Working Group]
* No one from Mozilla is currently participating.

Want to participate? Please contact [[User:Dbaron|David Baron]] and [[User:Tantek|Tantek]].

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

=== Social Web Working Group ===
SocialWG - http://www.w3.org/Social/WG
* [[User:Tantek|Tantek]] - co-chair

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

Specifications: SVG 1.1, SVG 2.0

=== System Applications Working Group ===
[http://www.w3.org/2012/sysapps/ SysApps] (System Applications) Working Group [https://www.w3.org/2000/09/dbwg/details?group=58119&public=1&order=org#_MozillaFoundation participants]:
* [[User:Brendan|Brendan Eich]]
* [[User:Sicking|Jonas Sicking]]
* [[User:Mounir.lamouri|Mounir Lamouri]]
* [[User:Tantek|Tantek Çelik]]

=== Tracking Protection Working Group ===
http://www.w3.org/2011/tracking-protection/
* Alex Fowler
* Thomas Lowenthal
* Sid Stamm

=== Technical Architecture Group ===
W3C [http://www.w3.org/2001/tag/ TAG]
* [[User:Annevk|Anne van Kesteren]]

=== Web Applications Working Group ===
WebApps WG
* Cameron McCormack
* [[User:Anant|Anant Narayanan]]
* Olli Pettay
* Arun Ranganathan
* [[User:Sicking|Jonas Sicking]]
* [[User:Tantek|Tantek Çelik]] (observer)
* [[User:Mounir.lamouri|Mounir Lamouri]]

Specifications: IndexedDB, Web IDL, XMLHttpRequest, DOM 3 Events, DOM 4, etc.

See also on this wiki:
* [[DOM]]
* [[WebAPI]]

=== Web Applications Security Working Group ===

* Eric Rescorla

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

=== Web Education Community Group ===
http://www.w3.org/community/webed/

* Schalk Neethling
* Jérémie Patonnier
* Janet Swisher

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

Specifications: Touch Events

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

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

Specifications: HTML living standard as developed by the WHATWG.

=== Web Media Text Tracks Community Group ===
http://www.w3.org/community/texttracks/
* Ralph Giles (:rillian)

Specifications: something [http://www.whatwg.org/specs/web-apps/current-work/webvtt.html WebVTT]-ish, we hope.

=== Web Payments Task Force ===

[http://www.w3.org/wiki/Payments_Task_Force http://www.w3.org/wiki/Payments_Task_Force]

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

=== Web Performance Working Group ===
* Cameron McCormack
* Kyle Simpson

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

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

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

=== Web Security Working Group (forming) ===
* Brandon Sterne
* Dan Veditz

Specifications: CSP, CORS (jointly with WebApps WG)

== WHATWG ==
Web Hypertext Application Technologies Working Group - http://whatwg.org
* [[User:Dbaron|David Baron]]
* [[User:Tantek|Tantek Çelik]]
* Brendan Eich
* Mounir Lamouri
* Jonas Sicking
* Henri Sivonen
* [[User:Annevk|Anne van Kesteren]]
* ...

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

= other =

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

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

== OASIS ==

* Mozilla point of contact: Gervase Markham
* PKCS#11 working group: Brian Smith

== XMPP ==
Mozilla is not formally associated with the XSF but has representation indirectly. http://xmpp.org/
* [[User:bear|Mike Taylor]] (bear) - elected board member

= emeritus =
== people ==
Former Mozillians who worked on standards:
* Chris Blizzard (til 2012-03-16)
** [[#IETF]]
** [[#rtcweb]]
** [[#WebRTC_Working_Group]]

== organizations and groups ==
=== Federated Social Web Incubator Group ===
2010-12-15 ... 2012-01-12 (transitioned to Federated Social Web Community Group)

W3C Federated Social Web Incubator Group (FSW XG)
http://www.w3.org/2005/Incubator/federatedsocialweb/ and [http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/Main_Page FSW wiki]
* David Ascher
* [[User:Mixedpuppy|Shane Caraveo]]
* [[User:Tantek|Tantek Çelik]]

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

= related =
See also:
* [[Events]] - which include web standards-related events.
* [[SEO/Standards]] - how to use standards to improve/optimize search results
* [[Standards/license]] - what license Mozilla prefers for standards specifications

Talk:JavaScript:New to SpiderMonkey

2014-12-12T04:49:02Z

Xfq: /* Benchmarking */ new section

== MQ workflow ==

In the ''Baseline version / Mercurial Queues'' section and the ''Example MQ workflow'' section, <code>hg qinit</code> and <code>hg qcommit</code> commands, as well as the <code>-f</code> option are deprecated. Can anyone familiar with MQ fix them? --[[User:Xfq|Xfq]] ([[User talk:Xfq|talk]]) 20:49, 7 December 2014 (PST)

== Benchmarking ==

The "Benchmark your changes" section illustrates how to use SunSpider
for benchmarking. Perhaps we should change it to a guide or link of
[https://github.com/h4writer/arewefastyet AWFY] instead of SunSpider-only. --[[User:Xfq|Xfq]] ([[User talk:Xfq|talk]]) 20:49, 11 December 2014 (PST)

Talk:JavaScript:New to SpiderMonkey

2014-12-12T04:47:40Z

Xfq: Add header.

JavaScript:New to SpiderMonkey

2014-12-10T00:31:30Z

Xfq: /* Get a real bug */ Change the Bugzilla link to Bugs Ahoy because the first link is "Zarro Boogs found".

== Tutorial: your first patch ==

The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.

We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.

=== Get the code ===

Spidermonkey development happens in the "mozilla-central" mercurial repository:

hg clone http://hg.mozilla.org/mozilla-central spidermonkey

=== Build the js shell ===

Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:

cd spidermonkey/js/src
autoconf2.13 # or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make
cd ..

If you're having trouble or are missing dependencies, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation#Building_SpiderMonkey_tip Building SpiderMonkey Tip].

=== Fix something ===

At this point, you're ready to make your first fix.

TODO: something useless. Maybe adding a datemicrosecond function.

==== Building your changes ====

Having made the change, build the shell again.

make -C build_DBG.OBJ

==== Testing your changes ====

It builds. Hurray. Time to run the tests to check you haven't broken anything.

jit-test/jit_test.py build_DBG.OBJ/dist/bin/js
(The location of the shell has changed, it used to be build_DBG.OBJ/js)

The jit-tests are pretty quick, and should give you an idea if you've gotten something wrong. Assuming nothing goes wrong, try the ref-tests:

tests/jstests.py build_DBG.OBJ/dist/bin/js

Note that some of these tests fail depending on the timezone and locale they're run in, so if you get any errors that don't seem related to your changes, re-run the tests with a shell build without your changes applied and compare the results.

==== Benchmark your changes ====

Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider

And now run them:

cd SunSpider
./sunspider --shell=../build_DBG.OBJ/dist/bin/js --run=30 --suite=sunspider-0.9.1
cd ..

===== Optimized build =====

Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.

mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure --disable-debug --enable-optimize
make
cd ..

Repeat the sunspider steps above, and take note of the line that looks like:

Results are located at sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

You'll need that later.

===== Baseline version / Mercurial Queues =====

We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which most people think is a pretty good way of managing their SpiderMonkey workflow:

hg qinit
hg qnew my_first_patch -f
hg qrefresh

This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:

hg qpop

And we're back to our pristine version.

===== Compare =====

Build again and rerun SunSpider again. You should now have two files like:

sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

Compare them using the compare script:

cd SunSpider
./sunspider-compare-results --shell=../build_DBG.OBJ/js --suite=sunspider-0.9.1 FILE1-withoutPatch FILE2-withPatch

=== Get a real bug ===

At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. You can get a bug on [http://www.joshmatthews.net/bugsahoy/?jseng=1&unowned=1 Bugs Ahoy].

Fix the bug, updating the bug report with your progress, and asking questions as you go (either in the bug comments, or in [irc://irc.mozilla.org/#jsapi #jsapi]). When it's done, repeat all the steps above. Then it's time to get your patch into the tree.

=== Submit a patch ===

To get the patch from mercurial, use:

hg qdiff # if you're using queues or
hg diff # if you're not

Add it to the bug as an attachment.

=== Get a review ===

Nothing gets into the tree without a review, so you'll need one. The [[JavaScript:Hackers|SpiderMonkey hackers list]] is a good place to start: if your patch changes something listed as an area of expertise for someone there, that's a good person to ask for a review.

Alternatively run <code>hg blame</code> on the files you've changed, and check who has been changing related code recently. They're likely to be good candidates.

The review will consist of comments on your changes, suggesting or requesting alternative ways to do something and asking you to make changes where needed. They might also request additional changes, for example tests. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they're mark the patch as "<code>r+</code>" meaning it's now good to commit.

=== Commit ===

You can't commit to mozilla-central / mozilla-inbound until you have "level 3" access, so you'll need someone to do this for you. Try asking in [irc://irc.mozilla.org/#jsapi #jsapi], or add the <code>checkin-needed</code> keyword to the bug. After you have been contributing for a while, you can get level 3 access by [https://www.mozilla.org/hacking/commit-access-policy/ applying for it].

After committing, a large series of tests will be run to make sure you didn't break anything. You'll need to hang around to make sure you didn't break something. Check [http://tbpl.mozilla.org/?tree=Firefox the Firefox tree] for failures. Sometimes failures will be spurious: ask [irc://irc.mozilla.org/#jsapi for help] determining when this is the case, to start. (Over time you'll figure out when this is and isn't the case yourself.)

== Overview of the JS engine ==

The JS engine is a swiftly moving target. The most detailed information is available at https://developer.mozilla.org/en/SpiderMonkey. Here are some particularly interesting, mostly up-to-date resources:

=== High level overviews ===

http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/

https://developer.mozilla.org/En/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h

Frequently used coding recipes and mappings from JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Cookbook

=== Detailed documentation ===

Build: https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation

Testing: https://developer.mozilla.org/en/SpiderMonkey/Running_Automated_JavaScript_Tests

Shell: https://developer.mozilla.org/En/SpiderMonkey/Introduction_to_the_JavaScript_shell

Function reference: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference

== Collaboration and teamwork ==

=== Communication (in descending order of information content) ===

Nearly all communication is handled through [https://bugzilla.mozilla.org Bugzilla]. All bugs, feature requests, issues, enhancements, etc, are all referred to as bugs. No code may enter the Mozilla repository without being a patch attached to a bugzilla bug first. To follow all SpiderMonkey related bugs:

Go to [https://bugzilla.mozilla.org/userprefs.cgi?tab=email email preferences]
Watch the user general@spidermonkey.bugs

SpiderMonkey contributors generally hang out in the very active [irc://irc.mozilla.org/jsapi #jsapi IRC channel].

The [https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals js-internals mailing list] is used for communicating with other SpiderMonkey hackers. (Internals as in discussing the internals of the SpiderMonkey engine. All are welcome on the list.).

Reading Planet Mozilla is the best way to keep up with the Mozilla project, which includes some SpiderMonkey related blogs:

[http://www.bailopan.net/blog/ David Anderson]
[http://blog.mozilla.com/rob-sayre/ Rob Sayre]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/dmandelin/ David Mandelin]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[http://blog.cdleary.com Chris Leary]

The Mozilla platform team has a [https://wiki.mozilla.org/Platform#Meetings public weekly meeting] where SpiderMonkey progress is (occasionally) discussed.

The [https://developer.mozilla.org/en/SpiderMonkey#Community js-engine mailing list] is generally used for communicating with people who embed SpiderMonkey, such as asking questions and announcing API changes. No actual development happens on the list.

== Code considerations ==

=== Repository ===

Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/mozilla-central mozilla-central] branch of the mozilla repository.

=== Coding Style ===

For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and virtual functions, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date.

=== Workflow ===

Everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the [http://hg.mozilla.org/mozilla-central mozilla-central repository]. A link to the commit is then added as a comment to the bug.

As well as committing to [http://hg.mozilla.org/mozilla-central mozilla-central], we also have the option of committing to [http://hg.mozilla.org/integration/mozilla-inbound mozilla-inbound], which is automatically merged to mozilla-central by a Sheriff. This exempts us from watching [http://tbpl.mozilla.org tinderbox] to check for errors in our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

[http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]

=== Policy ===

The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you should find reviewers in #jsapi rather than #developers.

[http://www.mozilla.org/hacking/committer/ How to get commit access]

[https://developer.mozilla.org/en/Creating_a_patch How to make patches]

[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch]

[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms]

==== .hgrc file ====

This .hgrc file contains a lot of the wisdom distilled through the wiki:

[extensions]
mq =

[ui]
username = First Last <email@domain.tld>

[alias]
qfulldiff = diff --rev qparent:.

[defaults]
diff = -p -U 8
qdiff = -p -U 8
qnew = -U
commit = -v

[diff]
git = true
showfunc = true
unified = 8

[paths]
try = ssh://email@domain.tld@hg.mozilla.org/try/

=== Try server ===

Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built and tested on tons of machines, which report to [http://tbpl.mozilla.org/?tree=Try TBPL]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.

=== Mercurial Queues ===

Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues.

Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above).

==== Enabling ====

Add the following snippet to your .hgrc file to enable MQ

[extensions]
mq =

==== Example MQ workflow ====

Clone the repository to deal with a bug:

hg clone http://hg.mozilla.org/mozilla-central

Initialize your queue:

hg qinit -c

Create a new patch, with some name:

hg qnew first_attempt

Work on the patch, try to fix the bug, test, compile, etc.

Refresh (save your work into the patch):

hg qrefresh

Repeat a few times.

Rename the patch (because your first name wasn't appliable):

hg qrename refactor_the_whatsit

Create a new patch to try a logically separate part of the same bug:

hg qnew rip_out_the_old_thing

Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches:

hg qpop # unapply a patch
hg qpush # reapply a patch
hg qpop -a # unapply all patches
hg qpush -a # reapply all patches

Combine all the patches into a single patch, which you submit to bugzilla:

hg qpush -a
hg qdiff --rev qparent:. > my_wonderful_patch.patch

Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically):

hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you"

Go back to the old patches and fiddle with them based on feedback:

hg qpop
hg qrefresh
etc

There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful!

[[Category:New Contributor Landing Page]]

Talk:JavaScript:New to SpiderMonkey

2014-12-08T04:49:59Z

Xfq: Some information about Mercurial is outdated.

In the ''Baseline version / Mercurial Queues'' section and the ''Example MQ workflow'' section, <code>hg qinit</code> and <code>hg qcommit</code> commands, as well as the <code>-f</code> option are deprecated. Can anyone familiar with MQ fix them? --[[User:Xfq|Xfq]] ([[User talk:Xfq|talk]]) 20:49, 7 December 2014 (PST)

User:Xfq

2014-12-02T04:33:01Z

Xfq:

I'm interested in JavaScript and SpiderMonkey.

Talk:Newsletters

2014-11-21T23:52:23Z

Xfq: /* 404 */ new section

There is no Firefox Aurora now, perhaps the "Aurora & Beta Channel Newsletters" should be renamed? --[[User:Xfq|Xfq]] ([[User talk:Xfq|talk]]) 15:44, 21 November 2014 (PST)

== 404 ==

"This Week In Browsing" is 404 now. --[[User:Xfq|Xfq]] ([[User talk:Xfq|talk]]) 15:52, 21 November 2014 (PST)

Talk:Newsletters

2014-11-21T23:44:15Z

Xfq: There is no Firefox Aurora now.

There is no Firefox Aurora now, perhaps the "Aurora & Beta Channel Newsletters" should be renamed? --[[User:Xfq|Xfq]] ([[User talk:Xfq|talk]]) 15:44, 21 November 2014 (PST)

Talk:Networking/Archive/Necko/Dashboard

2014-11-19T06:04:47Z

Xfq: The URL of the add-on is 404 now.

The URL of the add-on is 404 now. --[[User:Xfq|Xfq]] ([[User talk:Xfq|talk]]) 22:04, 18 November 2014 (PST)

XULRunner

2014-10-29T12:49:13Z

Xfq: MDC -> MDN

These pages on wiki.mozilla.org are about XULRunner development and planning. If you want more information about developing or using XULRunner-based applications, visit the [[MDN:XULRunner|Mozilla Developer Network]], which includes documentation on building, running, and deploying XULRunner.

* [[XULRunner:Roadmap|XULRunner Roadmap]]

== TODOs ==

A core requirement of XULRunner is the elimination of any app-specific
<code>#ifdef</code>s. It does us no good if portions of the toolkit are
<code>#ifdef MOZ_PHOENIX</code> or <code>#ifdef MOZ_THUNDERBIRD</code>. See the [http://developer.mozilla.org/docs/When_To_Use_ifdefs ifdef Manifesto].

The build system must be extended so that it is possible to build XULRunner in one objdir and applications in separate objdirs, propagating compiler feature tests from configure tests and keeping makefile configurations separate. See [[XULRunner:Build System Rework]].

== The XUL Development Kit ==

In addition to the XULRunner runtime, the XULRunner build process will produce a Development Kit which contains tools for building XUL applications and extensions. As a first goal, these tools will provide:

* A build environment without all of the complexity of the Mozilla system for applications which consist entirely of XUL+JS (no binary components). This environment will produce extension XPIs and various kinds of xulapp installers.

* Web and XUL development tools that already have been developed, including DOM Inspector and Venkman JS Debugger

* A reference tool which will contain quick reference information for web and XUL development with links to the full reference information from developer.mozilla.org.

After you have built XULRunner, try running the sample XULRunner application:

<pre>
$ cd dist/bin
$ ./xulrunner ../xpi-stage/simple/application.ini
</pre>

Not much to see, I know. But, take a look at the contents of the <code>xpi-stage/simple</code>
directory. Pretty simple (for a Mozilla-based app), wouldn't you say? (cough) Check out [http://lxr.mozilla.org/mozilla/source/xulrunner/examples/simple/application.ini application.ini]. See [http://developer.mozilla.org/en/docs/XUL_Application_Packaging XUL Application Packaging] for documentation on application.ini.

== User Profiles ==

An application running on top of the XULRunner has a fully
"managed" profile directory for storing user specific data.
XULRunner sets up the profile directory for applications
automatically, and it uses the same profile locking mechanism
used by existing applications like Firefox and Thunderbird.

The profile directory for an application is created under
vendor/appname in the appropriate place on the user's
system. For example, under Windows this would be:

$USERPROFILE\Application Data\$vendor\$appname\Profiles\$random.default

And under Unix systems it would be:

$HOME/.$vendor/$appname/Profiles/$random.default

Where <code>$vendor</code> and <code>$appname</code> are chosen by the
XUL application, and <code>$random</code> is generated by XULRunner to
obscure the location of the user's profile data.

The goal of this approach is to eliminate the need for the application
developer to think about profile details. The default configuration
should simply work without much fuss.

Down the road, we will want to allow XULRunner-based applications to
participate in profile sharing. The goal here is to allow applications
to share data that is common to the web platform such as SSL certificate,
cookies, and the web cache. (See also: [[Mozilla2:Profile Sharing]].)

== Versioning ==

XULRunner is a delivery vehicle for the XUL toolkit, which is not a frozen API.
It is an API that has historically evolved over time, and it will likely
continue to evolve for some time to come. While people agree that we need to
stablize that API, it will not happen overnight.

For these reasons, it is important that XULRunner support applications that
require specific versions of the toolkit. The current thinking is that
XULRunner will be versioned (with version number matching the corresponding
Gecko milestone), and applications will be able to specify the version(s) of
the toolkit that they require.

This is in fact already implemented as options in the <code>.xulapp</code> file.
Applications can specify a <code>MinVersion</code> and <code>MaxVersion</code>
for the toolkit versions they require. XULRunner will refuse to load an
application that does not pass the version test.

Some relatively old notes: [[XUL:Xul Runner Versioning]]

== Buglist ==

See also: [[XULRunner:Faq]]

*[https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Toolkit&component=XULRunner&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= XULRunner bugs]

*'''TODO -- Verify UA string''' Need to make sure that there is a clear distinction between the application's <code>{name, buildID, version}</code> info and the corresponding info for XULRunner itself. For example, the UA string still needs to be generated properly.

*'''TODO''' Need to support application icons. The best way to do this is have the app author provide a suite of PNGs in various sizes, and then convert these to the native OS format (.ico, .icns, .xbm) at app-install time. See [https://bugzilla.mozilla.org/show_bug.cgi?id=314651 bug 314651] and [https://bugzilla.mozilla.org/show_bug.cgi?id=314030 bug 314030]

*WorldMaker: In Windows icons for (say) .xulapp could be handled via a simple shell extension. [http://www.codeproject.com/shell/shellextguide9.asp An ATL example]

*Make it possible to run xulrunner + app from read only media (CDs). Would be great for demoing webapps with webservice support etc. Needs investigation, probably something that needs extensive volunteer help.

[[category:XULRunner|*]]

DevTools/GetInvolved

2014-09-08T02:21:24Z

Xfq: /* Resources */ Add DXR.

This page is the place to learn how to start contributing to the Firefox Developer Tools.

The Firefox Developer Tools are developed by the Mozilla community. We focus on building tools that make life easier for web (and mobile web) developers, addon developers, and Firefox developers. We hope the information on this page will help you become an active member of our community!

If after reading this wiki page, you still aren't sure what you're next steps are, [[#Communication|reach out to us on IRC]].

== Communication ==

* Twitter: [https://twitter.com/FirefoxDevTools @FirefoxDevTools]
* Mailing list: [https://lists.mozilla.org/listinfo/dev-developer-tools dev-developer-tools]
* Feedback channel: [http://mzl.la/devtools http://mzl.la/devtools]
* Blog (shared): [http://hacks.mozilla.org/ Mozilla Hacks]
* [[DevTools|Weekly phone calls]]

On top of that, we make heavy use of IRC chat in our day to day development. If you haven't used IRC before, check out the [[IRC|guide to getting started with IRC]].

We hang out in the '''#devtools''' channel at irc://irc.mozilla.org/devtools

If you have questions about a specific part of the code, here are some good people to ping:

* '''Console''': msucan, robcee
* '''Inspector''': pbrosset, bgrins, Optimizer, mikeratcliffe, paul
* '''Debugger''': past, vporof, fitzgen, jimb, robcee
* '''Style Editor''': harth, mikeratcliffe, paul
* '''Profiler''': vporof, robcee
* '''Network Monitor''': vporof, robcee
* '''Developer Toolbar''': jwalker, mikeratcliffe
* '''Scratchpad''': robcee, fitzgen, past
* '''WebIDE''': jryans, paul, ochameau, janx
* '''Firefox OS Simulator''': ochameau, paul, jryans, janx
* '''Tilt (3D View)''': vporof
* '''Canvas Debugger''': vporof
* '''WebGL Shader Editor''': vporof
* '''Web Audio Editor''': jsantell, vporof

== Reporting Bugs and Requesting Features ==

To report a bug/usability papercut/smaller feature/etc, [https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Developer%20Tools file a bug in the Developer Tools component] on Mozilla's Bugzilla.

If you have an idea for a new feature (or want to see what ideas have been submitted so far and their status), you can [http://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas propose it on uservoice].

Otherwise, you can also suggest larger features by [[#Communication|posting them to the mailing list]] where we can flesh the feature out as a community.

== Mentored and Good First Bugs ==

Our [http://mzl.la/1AcYOKF list of good first bugs] are bugs that have a mentor, and have been deemed good ones to start with. We also have a [http://mzl.la/1pqY2q8 list of all mentored bugs] if you are feeling more adventurous.

If you want to pick one of these up, feel free to ask for help in attacking the bug right in the bug itself, in [[#Communication|#devtools on irc.mozilla.org, or on the dev-developer-tools mailing list]]!

One more useful link: [https://bugzil.la/comp%3A%22Developer%20Tools%22 all open developer tools bugs] might have other items you'd find interesting to work on.

[[Category:New Contributor Landing Page]]

== Hacking ==

If you are ready to get the source code and start working on DevTools, check out our [[DevTools/Hacking|guide to hacking DevTools]].

== Resources ==

Here's a list of resources that you may find useful for hacking on DevTools. Feel free to add more if you find things are missing!

* [https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F How to format patches]
* [http://mxr.mozilla.org/mozilla-central/ MXR Code Search]
* [http://dxr.mozilla.org/mozilla-central/source/ DXR Code Search]
* [https://developer.mozilla.org/en-US/docs/Mercurial_FAQ Mercurial FAQ]
* [https://developer.mozilla.org/en-US/docs/Developer_Guide/mach mach]
* [http://flailingmonkey.com/bugzilla-tips-hacks-and-etiquette Bugzilla Tips, Hacks and Etiquette]
* [http://blog.margaretleibovic.com/post/36893756730/bugzilla-101 Bugzilla 101]
* [http://www.mozilla.org/hacking/commit-access-policy/ Commit access policy]
* [http://mozillians.org Mozillians Directory]
* [https://wiki.mozilla.org/ReleaseEngineering/TryServer Try Server]
* [https://wiki.mozilla.org/DevTools/Hacking Coding for DevTools]

Webdev/GetInvolved

2014-09-06T10:03:53Z

Xfq: Dev Derby has ended.

Get involved with making Mozilla's web sites even better. This page lists contribution opportunities that you're welcome to work on.

Most of the code on our sites is HTML, CSS, JavaScript and Django (Python) and you can read about how we do web development in the [http://mozweb.readthedocs.org Webdev Bootcamp].

If you have questions or are unsure how you can help, just ask on the [https://groups.google.com/forum/?fromgroups#!forum/mozilla.dev.webdev webdev forum] (to sign up to the forum as a mailing list, go to [https://lists.mozilla.org/listinfo/dev-webdev lists.mozilla.org/listinfo/dev-webdev]) or [irc://irc.mozilla.org#webdev IRC in #webdev] or talk to [https://twitter.com/potch @potch], [https://twitter.com/groovecoder @groovecoder] or [https://twitter.com/r1cky @r1cky] on Twitter.

{{FeaturedProject
|icon=firefox-100.jpg
|pagelocation=Webdev/GetInvolved/mozilla.org
|pagetitle=Featured Project: Mozilla.org
|description=Mozilla.org is the main web property for Mozilla products. [[Webdev/GetInvolved/mozilla.org#Mentored_Bugs|View List Of Mentored Tasks]] and [[Webdev/GetInvolved/mozilla.org|Learn More]]
}}

= Website Projects =
=== [[Webdev/GetInvolved/mozilla.org | www.mozilla.org]] ===
Having retired the Mozilla.com domain, Mozilla.org is now the main web property for Mozilla products and Engagement. Firefox, Thunderbird, Apps, B2G, Identity and Privacy, plus Press Center, Get Involved and others live under this domain.

* [[Webdev/GetInvolved/mozilla.org | Find out more about how to get involved with www.mozilla.org]]

=== [[Webdev/GetInvolved/addons.mozilla.org | addons.mozilla.org (AMO)]] ===
The [https://addons.mozilla.org Firefox Add-ons site] is a gallery of available customizations for the Firefox Web Browser. This is our highest trafficked website (20K+ hits per second) and uses technology like Memcached, Elasticsearch, RabbitMQ and Celery, and more.

=== [[Marketplace/Contributing/Code | Firefox Marketplace / marketplace.firefox.com]] ===
[https://marketplace.firefox.com Firefox Marketplace] has an API built on Django and several frontends using JavaScript. Some of these frontends run on websites and some are pre-loaded onto devices, providing a rich portal for users to be able to buy and sell open web apps on their desktop and mobile devices.

=== [[Webdev/GetInvolved/air.mozilla.org | air.mozilla.org]] ===
[https://air.mozilla.org Air Mozilla] is the Internet multimedia presence of Mozilla, with live and pre-recorded shows, interviews, news snippets, tutorial videos, and features about the Mozilla community.

* [[Webdev/GetInvolved/air.mozilla.org | Find out more about how to get involved with air.mozilla.org]]

=== [[Webdev/GetInvolved/support.mozilla.org | support.mozilla.org (SUMO)]] ===
[http://support.mozilla.org Mozilla Support] is the support site for Mozilla products. It helps millions of users every week through a knowledge base and support forum. It also provides collaboration and localization tools for the contributors. It uses technology like Python, Django, MySQL, Redis, Memcached, Elasticsearch and more.

* [[Webdev/GetInvolved/support.mozilla.org | Find out more about how to get involved with support.mozilla.org (SUMO)]]

=== [[Webdev/GetInvolved/developer.mozilla.org | developer.mozilla.org (MDN)]] ===
The [http://developer.mozilla.org Mozilla Developer Network] is our technical resource for developers - including documentation and demos for Mozilla and open web technologies.

* [[Webdev/GetInvolved/developer.mozilla.org | Find out more about how to get involved with developer.mozilla.org (MDN)]]

See also: [https://github.com/groovecoder/wp-promote-mdn/ Promote MDN WordPress plugin]

=== [[Webdev/GetInvolved/crash-stats.mozilla.org | crash-stats.mozilla.org (Socorro) ]] ===
Socorro is a server to accept and process Breakpad crash reports from Firefox, Thunderbird, etc.

* [[Webdev/GetInvolved/crash-stats.mozilla.org | Find out more about how to get involved with crash-stats.mozilla.org (Socorro) ]]

=== [[Webdev/GetInvolved/mozillians.org | mozillians.org (Mozillians)]] ===
This is a great first project to get involved! [http://mozillians.org/ Mozillians] is our community directory for core Mozilla volunteers and staff. It's a tool used by everyone involved with Mozilla, and it's the primary way that Mozillians can find each other. There are both front-end and back-end development opportunities, and we have mentors from the team to guide you through your first contributions.

* [[Webdev/GetInvolved/mozillians.org | Find out more about how to get involved with mozillians.org]]

=== [[Webdev/GetInvolved/reps.mozilla.org |reps.mozilla.org (ReMo)]] ===
The [https://reps.mozilla.org/ Mozilla Reps site] is where Mozilla Reps report their activities and share the events they run. There are both front-end and back-end development opportunities, and we have mentors to help you with your first contributions.

* [[Webdev/GetInvolved/reps.mozilla.org |Find out more about how to get involved with reps.mozilla.org]]

=== [[Webdev/GetInvolved/input.mozilla.org | input.mozilla.org ]] ===
[https://input.mozilla.org/ Firefox Input] is the user feedback system.

* [[Webdev/GetInvolved/input.mozilla.org | Find out more about how to get involved with input.mozilla.org ]]

=== [[Webdev/GetInvolved/careers.mozilla.org | careers.mozilla.org ]] ===
[https://careers.mozilla.org/ Careers] is the Mozilla jobs listings system.

* [[Webdev/GetInvolved/careers.mozilla.org | Find out more about how to get involved with careers.mozilla.org ]]

=== [http://dxr.mozilla.org dxr.mozilla.org] ===
DXR is Mozilla's code search and navigation tool, aimed at making sense of large projects like Firefox. It supports full-text and regex searches as well as structural queries like "Find all the callers of this function." Behind the scenes, it uses trigram indices, the re2 library, and structural data collected by a custom compiler plugin. A great project for folks interested in parsers or search.

* [[DXR | Get started here.]]

=== [[Webdev/GetInvolved/PluginCheck | PluginCheck]] ===
Most user know Plugin Check from pointing their browsers to [https://mozilla.org/plugincheck mozilla.org/plugincheck] but, there is a lot more to it than a single web page. There are some really interesting and challenging problems to help solve, from QA automation to improving the flow of reporting plugin updates and a whole bunch of JavaScript to be improved.

[[Webdev/GetInvolved/PluginCheck | Find out how you can get involved with PluginCheck]]

=== [[Webdev/GetInvolved/pontoon.mozilla.org |pontoon.mozilla.org]] ===
[https://pontoon.mozilla.org/ Pontoon] is an in-place localization tool. That means it enables localizers to translate web apps and websites right inside an app or website, with context and spatial limitations just in front of them. It is incredible.

* [[Webdev/GetInvolved/pontoon.mozilla.org |Find out more about how to get involved with Pontoon]]

= WordPress =
Mozilla runs a number of WordPress sites, and has developed a number of WordPress plugins.

* [[Webdev/GetInvolved/WordPress | Find out more about how to get involved with WordPress projects]]

= Libraries =

We've got lots of libraries we've written, many of which are looking for help.

=== [[Webdev/GetInvolved/django-browserid |django-browserid]] ===
Django library providing BrowserID/Persona based authentication.

* [[Webdev/GetInvolved/django-browserid |Find out more about how to get involved with django-browserid]]

=== [https://github.com/andymckay/django-paranoia django-paranoia] ===
Django library for warning people about attempted security intrusions.

=== [https://github.com/andymckay/django-statsd django-statsd] ===
Django library for creating metrics using Graphite and Statsd.

= Firefox OS =

If you are interested in HTML, CSS, and JavaScript, we could also use your help building our new [http://www.mozilla.org/firefoxos/ Firefox OS]. Find out more about how to help with that:

* https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Platform/Gaia/Hacking

= Learning Web Development =

If you're interested in learning more about web development and how the web works, you may be interested in our Webmaker project:

* https://webmaker.org/

= Web Technology Demos =

The [https://developer.mozilla.org/demos Mozilla Demo Studio] is a platform for showing the world what you can do with the Web. Not an expert? No problem. Some of the most interesting demos (like [https://developer.cdn.mozilla.net/media/uploads/demos/t/u/tuxie/fa3427d4b07c782f827580b5016550bc/santas-media-queries_1319913515_demo_package/index.html Santa's Media Queries]) are actually pretty simple under the hood. As long as you have a sense of creativity and a passion for making things better, we would love to have you.

= Contributor Achievements =

You will earn these distinct Mozilla Contributor Achievements:

{| border="1"
| Name
| Mozilla Webdev Fork
| Mozilla Webdev Pull request
| Mozilla Webdev Merge
| Mozilla Webdev Merge 10
| Mozilla Webdev Merge 25
| Mozilla Webdev Merge 50
| Mozilla Webdev Merge 100
|-
| Description
| Fork a Mozilla Webdev repository on GitHub
| Submit a Pull request to a Webdev repository on GitHub
| Finish a Pull request to successful merge
| Finish 10 Pull requests to successful merge
| Finish 25 Pull requests to successful merge
| Finish 50 Pull requests to successful merge
| Finish 100 Pull requests to successful merge
|-
| Possible Recognitions
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
| [https://badges.mozilla.org/en-US/profiles/profile/webdev Badge]
|}

Gecko:Getting Started

2014-08-31T12:05:54Z

Xfq:

The first step is to download and build Mozilla or Firefox: see https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions

See the [http://www.mozilla.org/hacking/ information on hacking Mozilla] for how to work with the Mozilla project and coding conventions.

If you get stuck at any point, send a question to a Mozilla newsgroup, or get onto IRC at irc.mozilla.org, channel #developers. Do not give up, there are people who want to help you.

If you're looking for a "first bug" to get started with, check out [[Gecko:First Bugs]].

Gecko:Home Page

2014-08-31T11:28:25Z

Xfq: /* Are You In The Right Place? */

== Are You In The Right Place? ==
This wiki is concerned with development of the Gecko rendering engine itself. If you are a Web developer (building Web pages, sites, apps, etc.) and have questions about (X)HTML, XUL, CSS, DOM, or JavaScript then go to the [http://developer.mozilla.org/ Mozilla Developer Network].

== Planning ==

=== Feature Planning / Specs ===

Most feature planning should happen in Bugzilla, but for some things it's easier to map out a spec on the wiki first.

*[[Gecko:Line Breaking]]

*[[Gecko:Mouse Wheel Scrolling]]
** [[Gecko:Notes for mouse driver developers on Windows]]

*[[Necko: Electrolysis design and subprojects]]

*[[Necko: support sending OnDataAvailable() to other threads]]

*[[Gecko/Touch|Touch input and gestures]]

== Developer Resources ==
[[Frame inheritance hierarchy]] (dated May 18, 2008)

[http://www.mozilla.org/newlayout/doc/layout-2006-12-14/master.xhtml Mozilla's Layout Engine (Presentation by L. David Baron)] (dated Thursday, December 14, 2006, 13:30 PST

[[Gecko:Miscellaneous Notes]] Random documentation we don't yet know how to categorize.

[[Gecko:Task List]] If you're familiar with Gecko code and want to contribute.

[[Gecko:Testing Tasks]] if you're interested in getting started by helping with testing Gecko

[[Gecko:Getting Started]] If you're just beginning.

[[Gecko:Overview]] work-in-progress documentation giving an overview of how Gecko works

[[Gecko:Frequently Asked Questions]] Developers' FAQ.

[[Gecko:Wish List]] Architecture and implementation ideas.

[[Gecko:Content Team Minutes]] Agenda and minutes from the [[Content Team]]

[[Gecko:Layout Improvements]] Architectural improvements we should make in layout. Also see [[Gecko:Compositor]]

[[Gecko:Moving Plugins To Content]]

[[Gecko:Small Device Support]]

[[Gecko:Obsolete API]]

[[New stringbundle APIs]]

[[Font selection]] and [[Font selection/Default fonts]]

[[Gecko/XUL Box Model]]

[[CSSFrameConstructor]]

[[Gecko:GPU Acceleration]]

== Related Resources ==
XUL development happens at [[XUL:Home Page]].

B2G/QA/Bugzilla

2014-07-23T04:47:48Z

Xfq: /* Searching */ The "Product" for B2G is "Firefox OS" in Bugzilla.

= Intro to Bugzilla =
* If it's the first time you are using bugzilla I highly recommend; it's 2 years old, however it's a good general intro: [http://blog.johnath.com/2010/02/04/bugzilla-for-humans/ bugzilla-for-humans]
* More links in helpful information can be found here:
** [https://developer.mozilla.org/en-US/docs/Bugzilla https://developer.mozilla.org/en-US/docs/Bugzilla]
** https://developer.mozilla.org/en-US/docs/User:Triona/Bug_writing_guidelines
** https://quality.mozilla.org/docs/bugzilla/starter-kit/how-to-write-a-proper-bug/
** https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines
* Keep in mind that these are guidelines and not hard set rules.
== Tips and Tricks: ==
* [http://www.youtube.com/watch?v=14W-XguG--U Quick Searching by typing in firefox URL]
= Before Filing =
== Check for Dups ==
* Verify that there isn't a bug on it first
** Sometimes searching for the bug isn't easy. There's many ways to say what a bug is or how a bug is affected. Getting used to some of the terminology helps out greatly.

== Searching ==
One way to do searching:
* Go to : [https://bugzilla.mozilla.org/query.cgi?format=advanced the search page ]
* Under Classification, select the Client Software
* Under Product, select Firefox OS
* Select the appropriate Status/Resolution in terms of your search
** Optional:
** select Search by Change history
** place in the appropriate time of your search
* select Custom Search
** change the drop down to "Summary" or "Comment" or whatever you are searching for, change the middle to "contains the string" and in the text field type in your query
** add and/or logic based on your search

Note:
#If the Summary contains the appname, it makes it that much easier to search for that specific app
#People may use different terminology for the same meaning : ie VKB, SKB,Virtual Keyboard, Soft Keyboard,
#If the bug happens in a specific component that you are aware of, select that component ie if the bug happens in FMRadio, select Component FMRadio.

== Common Queries ==
* B2G Bugs filed today:
[https://bugzilla.mozilla.org/buglist.cgi?list_id=9793260&chfield=%5bBug%20creation%5d&chfieldfrom=-24h&known_name=B2G%20Gaia%20Bugs%20Filed%20Today&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Creporter%2Cresolution%2Cshort_desc&query_based_on=B2G%20Gaia%20Bugs%20Filed%20Today&chfieldto=Now&query_format=advanced|B2G Bugs Filed Today]
* Other Searches based on Triage can be found on the triage page:
** https://wiki.mozilla.org/B2G/Triage

== Know your audience ==
* who is your audience?
# developers : Make it easy for the developers to understand how to reproduce the bug; they are the ones fixing the bug you find!
# other qa : Make it easy for the other QA to reproduce your issue to verify if it's fixed or not
# PMs/EPMs/Releng Managers : They need to understand how critical the bug is to place fixing the bug in the schedule

= Creating a bug =
== Product/Components ==
* The product should be Firefox OS
* The Components depend on where the failure occurs:
** if it's a driver issue (gonk level), then it's most likely should be placed in the Vendcom
** if the bug happens in a core app such as email, then it should be placed in that component
** We are trying to stay away from using General; having said that if you cannot figure which component it should go in please use that as the last case scenario.
* We do suggest that you use other Firefox products such as Firefox for Android or Firefox Desktop to see if you can reproduce the bug. If it happens in other products, chances are it's a Gecko level bug.

== Title ==
=== Have a clear title ===
* be precise
** A title of a bug should describe the issue clearly and a reader can tell what the bug is by just the title alone; this helps with triaging the bug
* What, Where, When, Why, How are some questions that should be answered in the title.
== Build/Platform ==
Please list the Build you are using including the gecko /gaia pull as well as the device you are using.

You can use : https://github.com/Mozilla-TWQA/B2G-flash-tool/blob/master/check_versions.sh
in order to capture some of these details.

Example:
Gaia d65d0f7fa9cda0a41b98149e3c540a41eb27b11f
Gecko https://hg.mozilla.org/integration/b2g-inbound/rev/9a0b874c531b
BuildID 20140327113532
Version 31.0a1
ro.build.version.incremental=eng.tclxa.20131223.163538
ro.build.date=Mon Dec 23 16:36:04 CST 2013
Alcatel Open Fire

== Description/STR ==
* please be clear in the STRs; having a step by step of how you produce the issue makes it clear and concise on how you were able to hit the bug.
** This allows the developer to reproduce how you got there and where the issue may lie.

== Expected Results ==
* What you would expect from the steps provided.
** sometimes knowing what's expected helps the developer, because what you may expect might not be what was designed for the feature.

== Actual Results ==
* The result from your Steps to reproduce.

=== Template ===
* Link: [https://bugzilla.mozilla.org/enter_bug.cgi?alias=&bug_severity=normal&bug_status=NEW&comment=*%20Environment%20%3A%20%0A%3Cphone%20version%3E%2C%20%3Cbuild%20id%3E%2C%20%3Cgaia%20timestamp%3E%0A%0A*%20Repro%20%3A%20%0A1.%0A%0A*%20Expected%20%3A%20%0A1.%0A%0A*%20Actual%20%3A%20%0A1.%0A%0A%23%20Note%20%3A%0A%23%23%20Spec%20PDF%3A%0A%23%23%20Page%20%3A%20%0A&component=Gaia&contenttypeentry=&contenttypemethod=autodetect&contenttypeselection=text%2Fplain&data=&short_desc=%5b%3CApp%20Name%3E%5d&form_name=enter_bug&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=Gonk%20(Firefox%20OS)&product=Firefox%20OS&qa_contact=&rep_platform=ARM create a new bug]

* Template
<pre>
Summary: [<appname/Area>] :

## Environment :
<phone version>, <build id> <gaia timestamp>

## Repro :
1.

## Expected :
1.

## Actual :
1.

## Note :
</pre>

* Example:
see {{bug|804883}}, {{bug|797140}} for examples.

== Attachments ==
When creating a bug, be sure to add any information that will help
* any logs / [http://shizen008.wordpress.com/2012/09/13/logcatting-on-b2g/ logcat]
* crash reports
* OOM (adb shell dmesg)
* any screenshots
* any images
* any videos
* any other information/attachments

== Other important items to fill ==
* Whiteboard tags:
** [b2g-desktop-builds] : for desktop builds
** regression
** [b2g-crash] : a crash that happens in b2g (note bugs could move to core if it is found to be a gecko crasher so it makes it easier to track crashing bugs this way.

* Keyword tags:
** qawanted : bugs that need QA to help provide more information
** polish : when it's a fixing/cleaning up the look and feel; it may not necessarily be blocking
** steps-wanted : need repro steps
** crash : a crashing bug
** hang : hanging bug
** [https://bugzilla.mozilla.org/describekeywords.cgi Other keywords]

* Flags:
** Blocking-name of release ?
*** ex 1.3?; 1.4?; 1.5?
** status-b2g-v(version)
*** which version(s) the bug is affecting such as status-b2g-v1.3: affected

* Crashes:
** if you crashed, having the crash id helps. Please try to get that information from :
adb shell ls -l /data/b2g/mozilla/Crash\ Reports/submitted/

== Filed a Bug? There's more things to do! ==
* check if it's a regression
** If it is a regression; tag it with the keywords: "regression" and "regressionwindow-wanted"
*** find out the regression range and remove the regressionwindow-wanted.
* If it's a crash in b2g, whiteboard the bug "[crash-b2g]" keyword the bug "crash"
* If it's a SUMO bug, whiteboard the bug "[SUMO-b2g]"
* If it's a Gaia UI automation test was disabled because of a bug, whiteboard tag "xfail"

= Misc =
== Advanced Info ==
[https://wiki.mozilla.org/B2G/QA/Bugzilla/Advanced https://wiki.mozilla.org/B2G/QA/Bugzilla/Advanced]

== FAQ ==
[https://wiki.mozilla.org/B2G/QA/Bugzilla/FAQ https://wiki.mozilla.org/B2G/QA/Bugzilla/FAQ]

== Other information on B2G/Gaia ==
* [https://wiki.mozilla.org/B2G/QA#Resources QA Resources]
* [https://wiki.mozilla.org/B2G/QA#Environments Environment and Flashing Images]

B2G/QA/Bugzilla

2014-07-23T04:44:06Z

Xfq: /* Searching */ Update the URI of the search page.

= Intro to Bugzilla =
* If it's the first time you are using bugzilla I highly recommend; it's 2 years old, however it's a good general intro: [http://blog.johnath.com/2010/02/04/bugzilla-for-humans/ bugzilla-for-humans]
* More links in helpful information can be found here:
** [https://developer.mozilla.org/en-US/docs/Bugzilla https://developer.mozilla.org/en-US/docs/Bugzilla]
** https://developer.mozilla.org/en-US/docs/User:Triona/Bug_writing_guidelines
** https://quality.mozilla.org/docs/bugzilla/starter-kit/how-to-write-a-proper-bug/
** https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines
* Keep in mind that these are guidelines and not hard set rules.
== Tips and Tricks: ==
* [http://www.youtube.com/watch?v=14W-XguG--U Quick Searching by typing in firefox URL]
= Before Filing =
== Check for Dups ==
* Verify that there isn't a bug on it first
** Sometimes searching for the bug isn't easy. There's many ways to say what a bug is or how a bug is affected. Getting used to some of the terminology helps out greatly.

== Searching ==
One way to do searching:
* Go to : [https://bugzilla.mozilla.org/query.cgi?format=advanced the search page ]
* Under Classification, select the Client Software
* Under Product, select Boot2Gecko
* select the appropriate Status/Resolution in terms of your search
** Optional :
** select Search by Change history
** place in the appropriate time of your search
* select Custom Search
** change the drop down to "Summary" or "Comment" or whatever you are searching for, change the middle to "contains the string" and in the text field type in your query
** add and/or logic based on your search

Note:
#if the Summary contains the appname, it makes it that much easier to search for that specific app
#People may use different terminology for the same meaning : ie VKB, SKB,Virtual Keyboard, Soft Keyboard,
#if the bug happens in a specific component that you are aware of, select that component ie if the bug happens in FMRadio, select Component FMRadio.

== Common Queries ==
* B2G Bugs filed today:
[https://bugzilla.mozilla.org/buglist.cgi?list_id=9793260&chfield=%5bBug%20creation%5d&chfieldfrom=-24h&known_name=B2G%20Gaia%20Bugs%20Filed%20Today&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Creporter%2Cresolution%2Cshort_desc&query_based_on=B2G%20Gaia%20Bugs%20Filed%20Today&chfieldto=Now&query_format=advanced|B2G Bugs Filed Today]
* Other Searches based on Triage can be found on the triage page:
** https://wiki.mozilla.org/B2G/Triage

== Know your audience ==
* who is your audience?
# developers : Make it easy for the developers to understand how to reproduce the bug; they are the ones fixing the bug you find!
# other qa : Make it easy for the other QA to reproduce your issue to verify if it's fixed or not
# PMs/EPMs/Releng Managers : They need to understand how critical the bug is to place fixing the bug in the schedule

= Creating a bug =
== Product/Components ==
* The product should be Firefox OS
* The Components depend on where the failure occurs:
** if it's a driver issue (gonk level), then it's most likely should be placed in the Vendcom
** if the bug happens in a core app such as email, then it should be placed in that component
** We are trying to stay away from using General; having said that if you cannot figure which component it should go in please use that as the last case scenario.
* We do suggest that you use other Firefox products such as Firefox for Android or Firefox Desktop to see if you can reproduce the bug. If it happens in other products, chances are it's a Gecko level bug.

== Title ==
=== Have a clear title ===
* be precise
** A title of a bug should describe the issue clearly and a reader can tell what the bug is by just the title alone; this helps with triaging the bug
* What, Where, When, Why, How are some questions that should be answered in the title.
== Build/Platform ==
Please list the Build you are using including the gecko /gaia pull as well as the device you are using.

You can use : https://github.com/Mozilla-TWQA/B2G-flash-tool/blob/master/check_versions.sh
in order to capture some of these details.

Example:
Gaia d65d0f7fa9cda0a41b98149e3c540a41eb27b11f
Gecko https://hg.mozilla.org/integration/b2g-inbound/rev/9a0b874c531b
BuildID 20140327113532
Version 31.0a1
ro.build.version.incremental=eng.tclxa.20131223.163538
ro.build.date=Mon Dec 23 16:36:04 CST 2013
Alcatel Open Fire

== Description/STR ==
* please be clear in the STRs; having a step by step of how you produce the issue makes it clear and concise on how you were able to hit the bug.
** This allows the developer to reproduce how you got there and where the issue may lie.

== Expected Results ==
* What you would expect from the steps provided.
** sometimes knowing what's expected helps the developer, because what you may expect might not be what was designed for the feature.

== Actual Results ==
* The result from your Steps to reproduce.

=== Template ===
* Link: [https://bugzilla.mozilla.org/enter_bug.cgi?alias=&bug_severity=normal&bug_status=NEW&comment=*%20Environment%20%3A%20%0A%3Cphone%20version%3E%2C%20%3Cbuild%20id%3E%2C%20%3Cgaia%20timestamp%3E%0A%0A*%20Repro%20%3A%20%0A1.%0A%0A*%20Expected%20%3A%20%0A1.%0A%0A*%20Actual%20%3A%20%0A1.%0A%0A%23%20Note%20%3A%0A%23%23%20Spec%20PDF%3A%0A%23%23%20Page%20%3A%20%0A&component=Gaia&contenttypeentry=&contenttypemethod=autodetect&contenttypeselection=text%2Fplain&data=&short_desc=%5b%3CApp%20Name%3E%5d&form_name=enter_bug&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=Gonk%20(Firefox%20OS)&product=Firefox%20OS&qa_contact=&rep_platform=ARM create a new bug]

* Template
<pre>
Summary: [<appname/Area>] :

## Environment :
<phone version>, <build id> <gaia timestamp>

## Repro :
1.

## Expected :
1.

## Actual :
1.

## Note :
</pre>

* Example:
see {{bug|804883}}, {{bug|797140}} for examples.

== Attachments ==
When creating a bug, be sure to add any information that will help
* any logs / [http://shizen008.wordpress.com/2012/09/13/logcatting-on-b2g/ logcat]
* crash reports
* OOM (adb shell dmesg)
* any screenshots
* any images
* any videos
* any other information/attachments

== Other important items to fill ==
* Whiteboard tags:
** [b2g-desktop-builds] : for desktop builds
** regression
** [b2g-crash] : a crash that happens in b2g (note bugs could move to core if it is found to be a gecko crasher so it makes it easier to track crashing bugs this way.

* Keyword tags:
** qawanted : bugs that need QA to help provide more information
** polish : when it's a fixing/cleaning up the look and feel; it may not necessarily be blocking
** steps-wanted : need repro steps
** crash : a crashing bug
** hang : hanging bug
** [https://bugzilla.mozilla.org/describekeywords.cgi Other keywords]

* Flags:
** Blocking-name of release ?
*** ex 1.3?; 1.4?; 1.5?
** status-b2g-v(version)
*** which version(s) the bug is affecting such as status-b2g-v1.3: affected

* Crashes:
** if you crashed, having the crash id helps. Please try to get that information from :
adb shell ls -l /data/b2g/mozilla/Crash\ Reports/submitted/

== Filed a Bug? There's more things to do! ==
* check if it's a regression
** If it is a regression; tag it with the keywords: "regression" and "regressionwindow-wanted"
*** find out the regression range and remove the regressionwindow-wanted.
* If it's a crash in b2g, whiteboard the bug "[crash-b2g]" keyword the bug "crash"
* If it's a SUMO bug, whiteboard the bug "[SUMO-b2g]"
* If it's a Gaia UI automation test was disabled because of a bug, whiteboard tag "xfail"

= Misc =
== Advanced Info ==
[https://wiki.mozilla.org/B2G/QA/Bugzilla/Advanced https://wiki.mozilla.org/B2G/QA/Bugzilla/Advanced]

== FAQ ==
[https://wiki.mozilla.org/B2G/QA/Bugzilla/FAQ https://wiki.mozilla.org/B2G/QA/Bugzilla/FAQ]

== Other information on B2G/Gaia ==
* [https://wiki.mozilla.org/B2G/QA#Resources QA Resources]
* [https://wiki.mozilla.org/B2G/QA#Environments Environment and Flashing Images]