MozillaWiki - User contributions [en]

Modules/Core

2021-03-10T01:15:13Z

Jorend: Change JS engine owner, delete some dead email addresses, fold js-ctypes module into JS engine

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

They may:

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

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

{{Module
|name=Animation
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.
|owner=[mailto:brian@birchill.co.jp Brian Birtles] (:birtles)
|peers=[mailto:boris@mozilla.com Boris Chiou] (:boris), [mailto:hikezoe.birchill@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)
|group=dev-platform
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko
|components=Core::DOM::Animation, Core::CSS Transitions and Animations
}}

{{Module
|name=Anti-Tracking
|description=Tracking detection and content-blocking.
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:dlee@mozilla.com Dimi Lee], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:xeonchen@gmail.com Gary Chen], [mailto:jhofmann@mozilla.com Johann Hofmann], [mailto:tihuang@mozilla.com Tim Huang]
|group=dev-platform
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/
|components=Core::Privacy: Anti-Tracking
}}

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

{{Module
|name=Build and Release Tools
|description=Tools related to build and release automation and configuration of release builds.
|owner=[mailto:bhearsum@mozilla.com Ben Hearsum]
|peers=[mailto:aki@mozilla.com Aki Sasaki]
|group=release-engineering
|source_dirs=tools/update-packaging/ tools/update-verify
|url=https://wiki.mozilla.org/ReleaseEngineering
|components=Release Engineering::*
}}

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

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

{{Module
|name=Content Security
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Referrer Policy, Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]
|peers=[mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston], [mailto:tnguyen@mozilla.com Thomas Nguyen]
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier
|group=dev-security
|source_dirs=dom/security
|components=Core::DOM: Security
}}

{{Module
|name=Cookies
|description=
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas]
|ownersemeritus=Monica Chew
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-platform
|source_dirs=netwerk/cookie/
|url=
|components=Core::Networking: Cookies
}}

{{Module
|name=Permissions
|description=
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]
|ownersemeritus=Monica Chew
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-platform
|source_dirs=extensions/permissions/
|url=
|components=Core :: Permission Manager
}}

{{Module
|name=Cycle Collector
|description=Code to break and collect objects within reference cycles
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]
|peers=Peter Van der Beken, Olli Pettay
|peersemeritus=David Baron
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers
|components=Core::XPCOM
|group=dev-platform
}}
{{Module
|name=C++/Rust usage, tools, and style
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:sgiesecke@mozilla.com Simon Giesecke]
|source_dirs=non-third-party C++ and Rust code in the tree
|components=Various components
|group=dev-platform
}}
{{Module
|name=docshell
|description=
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:sawang@mozilla.com Samael Wang], [mailto:kyle@nonpolynomial.com Kyle Machulis]
|group=dev-platform
|source_dirs=docshell/, uriloader/
|url=
|components=Core::Document Navigation
}}

{{Module
|name=Document Object Model
|description=
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell], [mailto:afarre@mozilla.com Andreas Farre], [mailto:emilio@crisal.io Emilio Cobos], [mailto:asuth@mozilla.com Andrew Sutherland], [mailto:echen@mozilla.com Edgar Chen]
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:ben@wanderview.com Ben Kelly], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-dom
|source_dirs=dom/*, except directories covered by other modules
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML
}}

{{Module
|name=DOM File
|description=DOM Blob, File and FileSystem APIs
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:olli@pettay.fi Olli Pettay]
|group=dev-platform
|source_dirs=dom/file, dom/filesystem
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM: File
}}

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

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

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

{{Module
|name=Editor
|description=
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

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

{{Module
|name=Global Key Bindings
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|group=dev-accessibility
|source_dirs=dom/events (and platform specific directories under it)
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
|components=Core::Keyboard: Navigation
}}

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

{{Module
|name=WebGPU (Graphics submodule)
|description=WebGPU implementation
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],
|group=dev-platform
|source_dirs=dom/webgpu
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU
|components=Core::Graphics::WebGPU
}}

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

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

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

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

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

{{Module
|name=I18N Library
|description=
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]
|group=dev-i18n
|source_dirs=intl/
|url=http://mozilla.org/projects/intl/index.html
|components=Core::Internationalization
}}

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

{{Module
|name=IPC
|description=Native message-passing between threads and processes
|owner=[mailto:jld@mozilla.com Jed Davis]
|ownersemeritus=Chris Jones, Bill McCloskey
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:amccreight@mozilla.com Andrew McCreight]
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

{{Module
|name=JavaScript
|description=JavaScript engine (SpiderMonkey)
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]
|peers=André Bargull, [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:jcoppeard@mozilla.com Jon Coppeard], [mailto:sphink@gmail.com Steve Fink], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:evilpies@gmail.com Tom Schuster], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ystartsev@mozilla.com Yulia Startsev], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:ccullen@mozilla.com Caroline Cullen], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:bobbyholley@gmail.com Bobby Holley]
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:wmccloskey@mozilla.com Bill McCloskey], Shu-yu Guo, Niko Matsakis, Eddy Bruel, [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], Andreas Gal, Eric Faust, Ashley Hauck, [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], Nicholas Nethercote, Jason Orendorff
|group=dev-tech-js-engine
|source_dirs=js/src
|url=http://www.mozilla.org/js/spidermonkey,
http://developer.mozilla.org/en/docs/About_JavaScript
|components=Core::JavaScript Engine
}}

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

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

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

{{Module
|name=Layout Engine
|description=rendering tree construction, layout (reflow), etc.
|owner=[mailto:dholbert@mozilla.com Daniel Holbert]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:mats@mozilla.com Mats Palmgren], [mailto:tlin@mozilla.com Ting-Yu Lin]
|ownersemeritus=[mailto:dbaron@dbaron.org David Baron]
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-platform
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/
|url=https://wiki.mozilla.org/Gecko:Overview#Layout
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Columns, Core::Layout: Flexbox, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: Generated Content, Lists, and Counters, Core::Layout: Grid, Core::Layout: Images, Video, and HTML Frames, Core::Layout: Positioned, Core::Layout: Ruby, Core::Layout: Scrolling and Overflow, Core::Layout: Tables, Core::Layout: Text and Fonts, Core::Print Preview, Core::Printing: Output
}}

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

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

{{Module
|name=Media Playback
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]
|group=dev-media
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/
|url=
|components=Core::Audio/Video
}}

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

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

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

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

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

{{Module
|name=MSCOM
|description=Integration with Microsoft Distributed COM
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]
|group=dev-platform
|source_dirs=ipc/mscom/%
|url=
|components=Core::IPC: MSCOM}}

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

{{Module
|name=NodeJS usage, tools, and style
|description=Advises on the use of NodeJS and npm packages at build and runtime. Reviews additions/upgrades/removals of vendored npm packages. Works with appropriate teams to maintain automated license and security audits of npm packages. Works with the security team and relevant developers to respond to vulnerabilities in NodeJS and vendored npm packages.
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]
|peers=[mailto:mbanner@mozilla.com Mark Banner], [mailto:dcoates@mozilla.com Danny Coates], [mailto:khudson@mozilla.com Kate Hudson], [mailto:elee@mozilla.com Ed Lee], [mailto:dtownsend@mozilla.com Dave Townsend]
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate
|components=Various components
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack
}}

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

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

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

{{Module
|name=Preferences
|description=Preference library
|owner=[mailto:kwright@mozilla.com Kris Wright]
|peers=[mailto:glandium@mozilla.com Mike Hommey], [mailto:kwright@mozilla.com Kris Wright]
|ownersemeritus=Nicholas Nethercote
|peersemeritus=Felipe Gomes, Eric Rahm
|group=dev-platform
|source_dirs=modules/libpref/
|url=
|components=Core::Preferences: Backend
}}

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

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

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

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:dueno@redhat.com Daiki Ueno]
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM
}}

{{Module
|name=Static analysis & rewriting for C++
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:eakhgari@mozilla.com Ehsan Akhgari]
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]
|group=dev-platform
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools
|url=
|components=Core::Rewriting & Analysis
}}
{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:erahm@mozilla.com Eric Rahm]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner=[mailto:emilio@crisal.io Emilio Cobos Álvarez]
|ownersemeritus=[mailto:dbaron@dbaron.org David Baron], [mailto:cam@mcc.id.au Cameron McCormack]
|peers=[mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan]
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-platform
|source_dirs=layout/style/, servo/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=UA String
|description=User Agent String
|owner=[mailto:tantek@mozilla.com Tantek Çelik]
|peers=[mailto:kdubost@mozilla.com Karl Dubost], [mailto:cpeterson@mozilla.com Chris Peterson], [mailto:hsivonen@mozilla.com Henri Sivonen]
|group=dev-platform
|source_dirs=netwerk/protocol/http/
|url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox
|components=Core::Networking: HTTP
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:mstange@themasta.com Markus Stange]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-platform
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:padenot@mozilla.com Paul Adenot]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=Web Painting
|description=painting, display lists, and layer construction
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]
|group=dev-platform
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses
|url=http://mozilla.org/newlayout/doc/ ,
http://lxr.mozilla.org/mozilla/source/layout/doc/
|components=Core::Layout: Web Painting
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC, Core::WebRTC Networking
}}

{{Module
|name=WebVR
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=dom/vr, gfx/vr
|url=https://mozvr.com/
|components=Core::WebVR
}}

{{Module
|name=Widget
|description=Top level Widget
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter],
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup
}}

{{Module
|name=Widget - Android
|description=Android widget support
|owner=[mailto:jwillcox@mozilla.com James Willcox]
|peers=
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=GTK widget support
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]
|peers=[mailto:stransky@redhat.com Martin Stránský]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - Headless
|description=Headless widget support
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]
|peers=
|ownersemeritus=
|group=dev-platform
|source_dirs=widget/headless/
|url=
|components=Firefox::Headless
}}

{{Module
|name=Widget - macOS
|description= macOS widget support
|owner=[mailto:spohl@mozilla.com Stephen A Pohl]
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:haftandilian@mozilla.com Haik Aftandilian]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widget support
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:cmartin@mozilla.com Chris Martin], [mailto:tkikuchi@mozilla.com Toshihito Kikuchi], [mailto:mhowell@mozilla.com Molly Howell], [mailto:aklotz@mozilla.com Aaron Klotz], [mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peersemeritus=[mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[mailto:nika@thelayzells.com Nika Layzell]
|peers=[mailto:kmaglione@mozilla.com Kris Maglione], [mailto:sgiesecke@mozilla.com Simon Giesecke]
|ownersemeritus=Benjamin Smedberg
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner], [mailto:erahm@mozilla.com Eric Rahm],
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:nika@thelayzells.com Nika Layzell]
|peers=[mailto:amccreight@mozilla.com Andrew McCreight]
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:davidp99@gmail.com David Parks] (:handyman), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:tkikuchi@mozilla.com Toshihito Kikuchi] (:toshi)
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]
|peers=
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux
|description=Sandboxing for the Linux platform
|owner=[mailto:jld@mozilla.com Jed Davis]
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Crash reporting
|description=Infrastructure and tools used to generate, submit and process crash reports. This includes the in-tree google-breakpad fork, the crash report generation machinery as well as the host tools used to dump symbols, analyse minidumps and generate stack traces.
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)
|peers=
|group=dev-platform
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html
|components=Toolkit::Crash Reporting
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]
|peers=Same as Build Config
|group=dev-builds
|components=Core::Build Config
}}

{{Module
|name=Build Config - Taskgraph
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.
|owner=[mailto:mozilla@hocat.ca Tom Prince]
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:dustin@mozilla.com Dustin Mitchell]
|components=Firefox Build System::Task Configuration
}}

{{Module
|name=WebRTC Media
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson],
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Audio/Video)
}}

{{Module
|name=WebRTC Signaling
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling
|owner=[mailto:bcampen@mozilla.com Byron Campen]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc/signaling/
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Signaling)
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::Find Backend
Core::General
Core::History: Global
Core::Image Blocking
Core::Localization
Core::Networking: Domain Lists
Core::Selection
Core::Serializers
Core::Spelling checker
Core::X-remote
Core::XUL
</pre>
</noinclude>

Modules/Core

2020-06-23T18:13:46Z

Jorend: Remove two JS peers

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

They may:

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

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

{{Module
|name=Animation
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)
|group=dev-tech-layout
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko
|components=Core::DOM::Animation, Core::CSS Transitions and Animations
}}

{{Module
|name=Anti-Tracking
|description=Tracking detection and content-blocking.
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:dlee@mozilla.com Dimi Lee], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:xeonchen@gmail.com Gary Chen], [mailto:jhofmann@mozilla.com Johann Hofmann], [mailto:tihuang@mozilla.com Tim Huang]
|group=dev-platform
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/
|components=Core::Privacy: Anti-Tracking
}}

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

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

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

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

{{Module
|name=Content Security
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Referrer Policy, Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]
|peers=[mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston], [mailto:tnguyen@mozilla.com Thomas Nguyen]
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier
|group=dev-security
|source_dirs=dom/security
|components=Core::DOM: Security
}}

{{Module
|name=Cookies
|description=
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas]
|ownersemeritus=Monica Chew
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-platform
|source_dirs=netwerk/cookie/
|url=
|components=Core::Networking: Cookies
}}

{{Module
|name=Permissions
|description=
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]
|ownersemeritus=Monica Chew
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-platform
|source_dirs=extensions/permissions/
|url=
|components=Core :: Permission Manager
}}

{{Module
|name=Cycle Collector
|description=Code to break and collect objects within reference cycles
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]
|peers=Peter Van der Beken, Olli Pettay, David Baron
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers
|components=Core::XPCOM
|group=dev-platform
}}
{{Module
|name=C++/Rust usage, tools, and style
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:sgiesecke@mozilla.com Simon Giesecke]
|source_dirs=non-third-party C++ and Rust code in the tree
|components=Various components
|group=dev-platform
}}
{{Module
|name=docshell
|description=
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:sawang@mozilla.com Samael Wang], [mailto:kyle@nonpolynomial.com Kyle Machulis]
|group=dev-platform
|source_dirs=docshell/, uriloader/
|url=
|components=Core::Document Navigation
}}

{{Module
|name=Document Object Model
|description=
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell], [mailto:afarre@mozilla.com Andreas Farre], [mailto:emilio@crisal.io Emilio Cobos]
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:ben@wanderview.com Ben Kelly], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-dom
|source_dirs=dom/*, except directories covered by other modules
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML
}}

{{Module
|name=DOM File
|description=DOM Blob, File and FileSystem APIs
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:olli@pettay.fi Olli Pettay]
|group=dev-platform
|source_dirs=dom/file, dom/filesystem
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM: File
}}

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

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

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

{{Module
|name=Editor
|description=
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

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

{{Module
|name=Global Key Bindings
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|group=dev-accessibility
|source_dirs=dom/events (and platform specific directories under it)
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
|components=Core::Keyboard: Navigation
}}

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

{{Module
|name=WebGPU (Graphics submodule)
|description=WebGPU implementation
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],
|group=dev-platform
|source_dirs=dom/webgpu
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU
|components=Core::Graphics::WebGPU
}}

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

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

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

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

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

{{Module
|name=I18N Library
|description=
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]
|group=dev-i18n
|source_dirs=intl/
|url=http://mozilla.org/projects/intl/index.html
|components=Core::Internationalization
}}

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

{{Module
|name=IPC
|description=Native message-passing between threads and processes
|owner=[mailto:jld@mozilla.com Jed Davis]
|ownersemeritus=Chris Jones, Bill McCloskey
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

{{Module
|name=JavaScript
|description=JavaScript engine (SpiderMonkey)
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], André Bargull, [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:jcoppeard@mozilla.com Jon Coppeard], [mailto:sphink@gmail.com Steve Fink], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:evilpies@gmail.com Tom Schuster], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ystartsev@mozilla.com Yulia Startsev], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:ccullen@mozilla.com Caroline Cullen], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:luke@mozilla.com Luke Wagner], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:bobbyholley@gmail.com Bobby Holley]
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], Andreas Gal, [mailto:efaust@mozilla.com Eric Faust], [mailto:khyperia@mozilla.com Ashley Hauck], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit]
|group=dev-tech-js-engine
|source_dirs=js/src
|url=http://www.mozilla.org/js/spidermonkey,
http://developer.mozilla.org/en/docs/About_JavaScript
|components=Core::JavaScript Engine
}}

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

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

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

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

{{Module
|name=Layout Engine
|description=rendering tree construction, layout (reflow), etc.
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:emilio@crisal.io Emilio Cobos Álvarez]
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/
|url=https://wiki.mozilla.org/Gecko:Overview#Layout
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Columns, Core::Layout: Flexbox, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: Generated Content, Lists, and Counters, Core::Layout: Grid, Core::Layout: Images, Video, and HTML Frames, Core::Layout: Positioned, Core::Layout: Ruby, Core::Layout: Scrolling and Overflow, Core::Layout: Tables, Core::Layout: Text and Fonts, Core::Print Preview, Core::Printing: Output
}}

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

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

{{Module
|name=Media Playback
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]
|group=dev-media
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/
|url=
|components=Core::Audio/Video
}}

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

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

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

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

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

{{Module
|name=MSCOM
|description=Integration with Microsoft Distributed COM
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]
|group=dev-platform
|source_dirs=ipc/mscom/%
|url=
|components=Core::IPC: MSCOM}}

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

{{Module
|name=NodeJS usage, tools, and style
|description=Advises on the use of NodeJS and npm packages at build and runtime. Reviews additions/upgrades/removals of vendored npm packages. Works with appropriate teams to maintain automated license and security audits of npm packages. Works with the security team and relevant developers to respond to vulnerabilities in NodeJS and vendored npm packages.
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]
|peers=[mailto:mbanner@mozilla.com Mark Banner], [mailto:dcoates@mozilla.com Danny Coates], [mailto:khudson@mozilla.com Kate Hudson], [mailto:jlaster@mozilla.com Jason Laster], [mailto:elee@mozilla.com Ed Lee], [mailto:dtownsend@mozilla.com Dave Townsend]
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate
|components=Various components
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack
}}

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

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

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

{{Module
|name=Preferences
|description=Preference library
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm], [mailto:kwright@mozilla.com Kristen Wright]
|peersemeritus=Felipe Gomes
|group=dev-platform
|source_dirs=modules/libpref/
|url=
|components=Core::Preferences: Backend
}}

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

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

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

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:dueno@redhat.com Daiki Ueno]
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM
}}

{{Module
|name=Static analysis & rewriting for C++
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:eakhgari@mozilla.com Ehsan Akhgari]
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]
|group=dev-platform
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools
|url=
|components=Core::Rewriting & Analysis
}}
{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner=[mailto:cam@mcc.id.au Cameron McCormack]
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/style/, servo/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:mstange@themasta.com Markus Stange]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:padenot@mozilla.com Paul Adenot]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=Web Painting
|description=painting, display lists, and layer construction
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]
|group=dev-tech-layout
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses
|url=http://mozilla.org/newlayout/doc/ ,
http://lxr.mozilla.org/mozilla/source/layout/doc/
|components=Core::Layout: Web Painting
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC, Core::WebRTC Networking
}}

{{Module
|name=WebVR
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=dom/vr, gfx/vr
|url=https://mozvr.com/
|components=Core::WebVR
}}

{{Module
|name=Widget
|description=Top level Widget
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter],
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup
}}

{{Module
|name=Widget - Android
|description=Android widget support
|owner=[mailto:jwillcox@mozilla.com James Willcox]
|peers=
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=GTK widget support
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]
|peers=[mailto:stransky@redhat.com Martin Stránský]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - Headless
|description=Headless widget support
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]
|peers=
|ownersemeritus=
|group=dev-platform
|source_dirs=widget/headless/
|url=
|components=Firefox::Headless
}}

{{Module
|name=Widget - macOS
|description= macOS widget support
|owner=[mailto:spohl@mozilla.com Stephen A Pohl]
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:haftandilian@mozilla.com Haik Aftandilian]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widget support
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:aklotz@mozilla.com Aaron Klotz]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|peers=[mailto:erahm@mozilla.com Eric Rahm], [mailto:nika@thelayzells.com Nika Layzell], [mailto:kmaglione@mozilla.com Kris Maglione]
|ownersemeritus=Benjamin Smedberg
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:nika@thelayzells.com Nika Layzell]
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]
|peers=
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux
|description=Sandboxing for the Linux platform
|owner=[mailto:jld@mozilla.com Jed Davis]
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Crash reporting
|description=Infrastructure and tools used to generate, submit and process crash reports. This includes the in-tree google-breakpad fork, the crash report generation machinery as well as the host tools used to dump symbols, analyse minidumps and generate stack traces.
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj)
|group=dev-platform
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html
|components=Toolkit::Crash Reporting
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]
|peers=Same as Build Config
|group=dev-builds
|components=Core::Build Config
}}

{{Module
|name=Build Config - Taskgraph
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.
|owner=[mailto:mozilla@hocat.ca Tom Prince]
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:dustin@mozilla.com Dustin Mitchell]
|components=Firefox Build System::Task Configuration
}}

{{Module
|name=WebRTC Media
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson],
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Audio/Video)
}}

{{Module
|name=WebRTC Signaling
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling
|owner=[mailto:bcampen@mozilla.com Byron Campen]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc/signaling/
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Signaling)
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::Find Backend
Core::General
Core::History: Global
Core::Image Blocking
Core::Localization
Core::Networking: Domain Lists
Core::Selection
Core::Serializers
Core::Spelling checker
Core::X-remote
Core::XUL
</pre>
</noinclude>

Modules/Core

2020-06-23T15:42:30Z

Jorend: Add JS peer: caroline

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

They may:

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

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

{{Module
|name=Animation
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)
|group=dev-tech-layout
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko
|components=Core::DOM::Animation, Core::CSS Transitions and Animations
}}

{{Module
|name=Anti-Tracking
|description=Tracking detection and content-blocking.
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:dlee@mozilla.com Dimi Lee], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:xeonchen@gmail.com Gary Chen], [mailto:jhofmann@mozilla.com Johann Hofmann], [mailto:tihuang@mozilla.com Tim Huang]
|group=dev-platform
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/
|components=Core::Privacy: Anti-Tracking
}}

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

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

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

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

{{Module
|name=Content Security
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Referrer Policy, Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]
|peers=[mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston], [mailto:tnguyen@mozilla.com Thomas Nguyen]
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier
|group=dev-security
|source_dirs=dom/security
|components=Core::DOM: Security
}}

{{Module
|name=Cookies
|description=
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas]
|ownersemeritus=Monica Chew
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-platform
|source_dirs=netwerk/cookie/
|url=
|components=Core::Networking: Cookies
}}

{{Module
|name=Permissions
|description=
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]
|ownersemeritus=Monica Chew
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-platform
|source_dirs=extensions/permissions/
|url=
|components=Core :: Permission Manager
}}

{{Module
|name=Cycle Collector
|description=Code to break and collect objects within reference cycles
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]
|peers=Peter Van der Beken, Olli Pettay, David Baron
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers
|components=Core::XPCOM
|group=dev-platform
}}
{{Module
|name=C++/Rust usage, tools, and style
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:sgiesecke@mozilla.com Simon Giesecke]
|source_dirs=non-third-party C++ and Rust code in the tree
|components=Various components
|group=dev-platform
}}
{{Module
|name=docshell
|description=
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:sawang@mozilla.com Samael Wang], [mailto:kyle@nonpolynomial.com Kyle Machulis]
|group=dev-platform
|source_dirs=docshell/, uriloader/
|url=
|components=Core::Document Navigation
}}

{{Module
|name=Document Object Model
|description=
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell], [mailto:afarre@mozilla.com Andreas Farre], [mailto:emilio@crisal.io Emilio Cobos]
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:ben@wanderview.com Ben Kelly], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-dom
|source_dirs=dom/*, except directories covered by other modules
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML
}}

{{Module
|name=DOM File
|description=DOM Blob, File and FileSystem APIs
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:olli@pettay.fi Olli Pettay]
|group=dev-platform
|source_dirs=dom/file, dom/filesystem
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM: File
}}

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

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

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

{{Module
|name=Editor
|description=
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

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

{{Module
|name=Global Key Bindings
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|group=dev-accessibility
|source_dirs=dom/events (and platform specific directories under it)
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
|components=Core::Keyboard: Navigation
}}

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

{{Module
|name=WebGPU (Graphics submodule)
|description=WebGPU implementation
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],
|group=dev-platform
|source_dirs=dom/webgpu
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU
|components=Core::Graphics::WebGPU
}}

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

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

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

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

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

{{Module
|name=I18N Library
|description=
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]
|group=dev-i18n
|source_dirs=intl/
|url=http://mozilla.org/projects/intl/index.html
|components=Core::Internationalization
}}

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

{{Module
|name=IPC
|description=Native message-passing between threads and processes
|owner=[mailto:jld@mozilla.com Jed Davis]
|ownersemeritus=Chris Jones, Bill McCloskey
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

{{Module
|name=JavaScript
|description=JavaScript engine (SpiderMonkey)
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], André Bargull, [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:jcoppeard@mozilla.com Jon Coppeard], [mailto:sphink@gmail.com Steve Fink], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:evilpies@gmail.com Tom Schuster], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ystartsev@mozilla.com Yulia Startsev], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:ccullen@mozilla.com Caroline Cullen] [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:luke@mozilla.com Luke Wagner], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:bobbyholley@gmail.com Bobby Holley]
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], Andreas Gal, [mailto:efaust@mozilla.com Eric Faust], [mailto:khyperia@mozilla.com Ashley Hauck]
|group=dev-tech-js-engine
|source_dirs=js/src
|url=http://www.mozilla.org/js/spidermonkey,
http://developer.mozilla.org/en/docs/About_JavaScript
|components=Core::JavaScript Engine
}}

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

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

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

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

{{Module
|name=Layout Engine
|description=rendering tree construction, layout (reflow), etc.
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:emilio@crisal.io Emilio Cobos Álvarez]
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/
|url=https://wiki.mozilla.org/Gecko:Overview#Layout
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Columns, Core::Layout: Flexbox, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: Generated Content, Lists, and Counters, Core::Layout: Grid, Core::Layout: Images, Video, and HTML Frames, Core::Layout: Positioned, Core::Layout: Ruby, Core::Layout: Scrolling and Overflow, Core::Layout: Tables, Core::Layout: Text and Fonts, Core::Print Preview, Core::Printing: Output
}}

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

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

{{Module
|name=Media Playback
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]
|group=dev-media
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/
|url=
|components=Core::Audio/Video
}}

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

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

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

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

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

{{Module
|name=MSCOM
|description=Integration with Microsoft Distributed COM
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]
|group=dev-platform
|source_dirs=ipc/mscom/%
|url=
|components=Core::IPC: MSCOM}}

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

{{Module
|name=NodeJS usage, tools, and style
|description=Advises on the use of NodeJS and npm packages at build and runtime. Reviews additions/upgrades/removals of vendored npm packages. Works with appropriate teams to maintain automated license and security audits of npm packages. Works with the security team and relevant developers to respond to vulnerabilities in NodeJS and vendored npm packages.
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]
|peers=[mailto:mbanner@mozilla.com Mark Banner], [mailto:dcoates@mozilla.com Danny Coates], [mailto:khudson@mozilla.com Kate Hudson], [mailto:jlaster@mozilla.com Jason Laster], [mailto:elee@mozilla.com Ed Lee], [mailto:dtownsend@mozilla.com Dave Townsend]
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate
|components=Various components
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack
}}

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

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

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

{{Module
|name=Preferences
|description=Preference library
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm], [mailto:kwright@mozilla.com Kristen Wright]
|peersemeritus=Felipe Gomes
|group=dev-platform
|source_dirs=modules/libpref/
|url=
|components=Core::Preferences: Backend
}}

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

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

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

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:dueno@redhat.com Daiki Ueno]
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM
}}

{{Module
|name=Static analysis & rewriting for C++
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:eakhgari@mozilla.com Ehsan Akhgari]
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]
|group=dev-platform
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools
|url=
|components=Core::Rewriting & Analysis
}}
{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner=[mailto:cam@mcc.id.au Cameron McCormack]
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/style/, servo/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:mstange@themasta.com Markus Stange]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:padenot@mozilla.com Paul Adenot]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=Web Painting
|description=painting, display lists, and layer construction
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]
|group=dev-tech-layout
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses
|url=http://mozilla.org/newlayout/doc/ ,
http://lxr.mozilla.org/mozilla/source/layout/doc/
|components=Core::Layout: Web Painting
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC, Core::WebRTC Networking
}}

{{Module
|name=WebVR
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=dom/vr, gfx/vr
|url=https://mozvr.com/
|components=Core::WebVR
}}

{{Module
|name=Widget
|description=Top level Widget
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter],
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup
}}

{{Module
|name=Widget - Android
|description=Android widget support
|owner=[mailto:jwillcox@mozilla.com James Willcox]
|peers=
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=GTK widget support
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]
|peers=[mailto:stransky@redhat.com Martin Stránský]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - Headless
|description=Headless widget support
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]
|peers=
|ownersemeritus=
|group=dev-platform
|source_dirs=widget/headless/
|url=
|components=Firefox::Headless
}}

{{Module
|name=Widget - macOS
|description= macOS widget support
|owner=[mailto:spohl@mozilla.com Stephen A Pohl]
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:haftandilian@mozilla.com Haik Aftandilian]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widget support
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:aklotz@mozilla.com Aaron Klotz]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|peers=[mailto:erahm@mozilla.com Eric Rahm], [mailto:nika@thelayzells.com Nika Layzell], [mailto:kmaglione@mozilla.com Kris Maglione]
|ownersemeritus=Benjamin Smedberg
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:nika@thelayzells.com Nika Layzell]
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]
|peers=
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux
|description=Sandboxing for the Linux platform
|owner=[mailto:jld@mozilla.com Jed Davis]
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Crash reporting
|description=Infrastructure and tools used to generate, submit and process crash reports. This includes the in-tree google-breakpad fork, the crash report generation machinery as well as the host tools used to dump symbols, analyse minidumps and generate stack traces.
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj)
|group=dev-platform
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html
|components=Toolkit::Crash Reporting
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]
|peers=Same as Build Config
|group=dev-builds
|components=Core::Build Config
}}

{{Module
|name=Build Config - Taskgraph
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.
|owner=[mailto:mozilla@hocat.ca Tom Prince]
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:dustin@mozilla.com Dustin Mitchell]
|components=Firefox Build System::Task Configuration
}}

{{Module
|name=WebRTC Media
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson],
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Audio/Video)
}}

{{Module
|name=WebRTC Signaling
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling
|owner=[mailto:bcampen@mozilla.com Byron Campen]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc/signaling/
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Signaling)
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::Find Backend
Core::General
Core::History: Global
Core::Image Blocking
Core::Localization
Core::Networking: Domain Lists
Core::Selection
Core::Serializers
Core::Spelling checker
Core::X-remote
Core::XUL
</pre>
</noinclude>

Modules/Core

2020-06-23T15:03:00Z

Jorend: Add three JS peers: nbp, iain, mgaudet

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

They may:

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

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

{{Module
|name=Animation
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)
|group=dev-tech-layout
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko
|components=Core::DOM::Animation, Core::CSS Transitions and Animations
}}

{{Module
|name=Anti-Tracking
|description=Tracking detection and content-blocking.
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:dlee@mozilla.com Dimi Lee], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:xeonchen@gmail.com Gary Chen], [mailto:jhofmann@mozilla.com Johann Hofmann], [mailto:tihuang@mozilla.com Tim Huang]
|group=dev-platform
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/
|components=Core::Privacy: Anti-Tracking
}}

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

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

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

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

{{Module
|name=Content Security
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Referrer Policy, Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]
|peers=[mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston], [mailto:tnguyen@mozilla.com Thomas Nguyen]
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier
|group=dev-security
|source_dirs=dom/security
|components=Core::DOM: Security
}}

{{Module
|name=Cookies
|description=
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas]
|ownersemeritus=Monica Chew
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-platform
|source_dirs=netwerk/cookie/
|url=
|components=Core::Networking: Cookies
}}

{{Module
|name=Permissions
|description=
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]
|ownersemeritus=Monica Chew
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-platform
|source_dirs=extensions/permissions/
|url=
|components=Core :: Permission Manager
}}

{{Module
|name=Cycle Collector
|description=Code to break and collect objects within reference cycles
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]
|peers=Peter Van der Beken, Olli Pettay, David Baron
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers
|components=Core::XPCOM
|group=dev-platform
}}
{{Module
|name=C++/Rust usage, tools, and style
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:sgiesecke@mozilla.com Simon Giesecke]
|source_dirs=non-third-party C++ and Rust code in the tree
|components=Various components
|group=dev-platform
}}
{{Module
|name=docshell
|description=
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:sawang@mozilla.com Samael Wang], [mailto:kyle@nonpolynomial.com Kyle Machulis]
|group=dev-platform
|source_dirs=docshell/, uriloader/
|url=
|components=Core::Document Navigation
}}

{{Module
|name=Document Object Model
|description=
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell], [mailto:afarre@mozilla.com Andreas Farre], [mailto:emilio@crisal.io Emilio Cobos]
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:ben@wanderview.com Ben Kelly], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-dom
|source_dirs=dom/*, except directories covered by other modules
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML
}}

{{Module
|name=DOM File
|description=DOM Blob, File and FileSystem APIs
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:olli@pettay.fi Olli Pettay]
|group=dev-platform
|source_dirs=dom/file, dom/filesystem
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM: File
}}

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

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

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

{{Module
|name=Editor
|description=
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

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

{{Module
|name=Global Key Bindings
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|group=dev-accessibility
|source_dirs=dom/events (and platform specific directories under it)
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
|components=Core::Keyboard: Navigation
}}

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

{{Module
|name=WebGPU (Graphics submodule)
|description=WebGPU implementation
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],
|group=dev-platform
|source_dirs=dom/webgpu
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU
|components=Core::Graphics::WebGPU
}}

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

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

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

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

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

{{Module
|name=I18N Library
|description=
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]
|group=dev-i18n
|source_dirs=intl/
|url=http://mozilla.org/projects/intl/index.html
|components=Core::Internationalization
}}

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

{{Module
|name=IPC
|description=Native message-passing between threads and processes
|owner=[mailto:jld@mozilla.com Jed Davis]
|ownersemeritus=Chris Jones, Bill McCloskey
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

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

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

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

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

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

{{Module
|name=Layout Engine
|description=rendering tree construction, layout (reflow), etc.
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:emilio@crisal.io Emilio Cobos Álvarez]
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/
|url=https://wiki.mozilla.org/Gecko:Overview#Layout
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Columns, Core::Layout: Flexbox, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: Generated Content, Lists, and Counters, Core::Layout: Grid, Core::Layout: Images, Video, and HTML Frames, Core::Layout: Positioned, Core::Layout: Ruby, Core::Layout: Scrolling and Overflow, Core::Layout: Tables, Core::Layout: Text and Fonts, Core::Print Preview, Core::Printing: Output
}}

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

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

{{Module
|name=Media Playback
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]
|group=dev-media
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/
|url=
|components=Core::Audio/Video
}}

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

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

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

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

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

{{Module
|name=MSCOM
|description=Integration with Microsoft Distributed COM
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]
|group=dev-platform
|source_dirs=ipc/mscom/%
|url=
|components=Core::IPC: MSCOM}}

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

{{Module
|name=NodeJS usage, tools, and style
|description=Advises on the use of NodeJS and npm packages at build and runtime. Reviews additions/upgrades/removals of vendored npm packages. Works with appropriate teams to maintain automated license and security audits of npm packages. Works with the security team and relevant developers to respond to vulnerabilities in NodeJS and vendored npm packages.
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]
|peers=[mailto:mbanner@mozilla.com Mark Banner], [mailto:dcoates@mozilla.com Danny Coates], [mailto:khudson@mozilla.com Kate Hudson], [mailto:jlaster@mozilla.com Jason Laster], [mailto:elee@mozilla.com Ed Lee], [mailto:dtownsend@mozilla.com Dave Townsend]
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate
|components=Various components
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack
}}

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

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

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

{{Module
|name=Preferences
|description=Preference library
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm], [mailto:kwright@mozilla.com Kristen Wright]
|peersemeritus=Felipe Gomes
|group=dev-platform
|source_dirs=modules/libpref/
|url=
|components=Core::Preferences: Backend
}}

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

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

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

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:dueno@redhat.com Daiki Ueno]
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM
}}

{{Module
|name=Static analysis & rewriting for C++
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:eakhgari@mozilla.com Ehsan Akhgari]
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]
|group=dev-platform
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools
|url=
|components=Core::Rewriting & Analysis
}}
{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner=[mailto:cam@mcc.id.au Cameron McCormack]
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/style/, servo/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:mstange@themasta.com Markus Stange]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:padenot@mozilla.com Paul Adenot]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=Web Painting
|description=painting, display lists, and layer construction
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]
|group=dev-tech-layout
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses
|url=http://mozilla.org/newlayout/doc/ ,
http://lxr.mozilla.org/mozilla/source/layout/doc/
|components=Core::Layout: Web Painting
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC, Core::WebRTC Networking
}}

{{Module
|name=WebVR
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=dom/vr, gfx/vr
|url=https://mozvr.com/
|components=Core::WebVR
}}

{{Module
|name=Widget
|description=Top level Widget
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter],
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup
}}

{{Module
|name=Widget - Android
|description=Android widget support
|owner=[mailto:jwillcox@mozilla.com James Willcox]
|peers=
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=GTK widget support
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]
|peers=[mailto:stransky@redhat.com Martin Stránský]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - Headless
|description=Headless widget support
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]
|peers=
|ownersemeritus=
|group=dev-platform
|source_dirs=widget/headless/
|url=
|components=Firefox::Headless
}}

{{Module
|name=Widget - macOS
|description= macOS widget support
|owner=[mailto:spohl@mozilla.com Stephen A Pohl]
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:haftandilian@mozilla.com Haik Aftandilian]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widget support
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:aklotz@mozilla.com Aaron Klotz]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|peers=[mailto:erahm@mozilla.com Eric Rahm], [mailto:nika@thelayzells.com Nika Layzell], [mailto:kmaglione@mozilla.com Kris Maglione]
|ownersemeritus=Benjamin Smedberg
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:nika@thelayzells.com Nika Layzell]
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]
|peers=
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux
|description=Sandboxing for the Linux platform
|owner=[mailto:jld@mozilla.com Jed Davis]
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Crash reporting
|description=Infrastructure and tools used to generate, submit and process crash reports. This includes the in-tree google-breakpad fork, the crash report generation machinery as well as the host tools used to dump symbols, analyse minidumps and generate stack traces.
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj)
|group=dev-platform
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html
|components=Toolkit::Crash Reporting
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]
|peers=Same as Build Config
|group=dev-builds
|components=Core::Build Config
}}

{{Module
|name=Build Config - Taskgraph
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.
|owner=[mailto:mozilla@hocat.ca Tom Prince]
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:dustin@mozilla.com Dustin Mitchell]
|components=Firefox Build System::Task Configuration
}}

{{Module
|name=WebRTC Media
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson],
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Audio/Video)
}}

{{Module
|name=WebRTC Signaling
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling
|owner=[mailto:bcampen@mozilla.com Byron Campen]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc/signaling/
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Signaling)
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::Find Backend
Core::General
Core::History: Global
Core::Image Blocking
Core::Localization
Core::Networking: Domain Lists
Core::Selection
Core::Serializers
Core::Spelling checker
Core::X-remote
Core::XUL
</pre>
</noinclude>

Modules/Core

2020-06-23T14:57:43Z

Jorend: Add Yulia Startsev as JS peer

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

They may:

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

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

{{Module
|name=Animation
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)
|group=dev-tech-layout
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko
|components=Core::DOM::Animation, Core::CSS Transitions and Animations
}}

{{Module
|name=Anti-Tracking
|description=Tracking detection and content-blocking.
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:dlee@mozilla.com Dimi Lee], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:xeonchen@gmail.com Gary Chen], [mailto:jhofmann@mozilla.com Johann Hofmann], [mailto:tihuang@mozilla.com Tim Huang]
|group=dev-platform
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/
|components=Core::Privacy: Anti-Tracking
}}

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

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

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

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

{{Module
|name=Content Security
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Referrer Policy, Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]
|peers=[mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston], [mailto:tnguyen@mozilla.com Thomas Nguyen]
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier
|group=dev-security
|source_dirs=dom/security
|components=Core::DOM: Security
}}

{{Module
|name=Cookies
|description=
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas]
|ownersemeritus=Monica Chew
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-platform
|source_dirs=netwerk/cookie/
|url=
|components=Core::Networking: Cookies
}}

{{Module
|name=Permissions
|description=
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]
|ownersemeritus=Monica Chew
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-platform
|source_dirs=extensions/permissions/
|url=
|components=Core :: Permission Manager
}}

{{Module
|name=Cycle Collector
|description=Code to break and collect objects within reference cycles
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]
|peers=Peter Van der Beken, Olli Pettay, David Baron
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers
|components=Core::XPCOM
|group=dev-platform
}}
{{Module
|name=C++/Rust usage, tools, and style
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:sgiesecke@mozilla.com Simon Giesecke]
|source_dirs=non-third-party C++ and Rust code in the tree
|components=Various components
|group=dev-platform
}}
{{Module
|name=docshell
|description=
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:sawang@mozilla.com Samael Wang], [mailto:kyle@nonpolynomial.com Kyle Machulis]
|group=dev-platform
|source_dirs=docshell/, uriloader/
|url=
|components=Core::Document Navigation
}}

{{Module
|name=Document Object Model
|description=
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell], [mailto:afarre@mozilla.com Andreas Farre], [mailto:emilio@crisal.io Emilio Cobos]
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:ben@wanderview.com Ben Kelly], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-dom
|source_dirs=dom/*, except directories covered by other modules
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML
}}

{{Module
|name=DOM File
|description=DOM Blob, File and FileSystem APIs
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:olli@pettay.fi Olli Pettay]
|group=dev-platform
|source_dirs=dom/file, dom/filesystem
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM: File
}}

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

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

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

{{Module
|name=Editor
|description=
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

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

{{Module
|name=Global Key Bindings
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|group=dev-accessibility
|source_dirs=dom/events (and platform specific directories under it)
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
|components=Core::Keyboard: Navigation
}}

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

{{Module
|name=WebGPU (Graphics submodule)
|description=WebGPU implementation
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],
|group=dev-platform
|source_dirs=dom/webgpu
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU
|components=Core::Graphics::WebGPU
}}

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

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

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

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

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

{{Module
|name=I18N Library
|description=
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]
|group=dev-i18n
|source_dirs=intl/
|url=http://mozilla.org/projects/intl/index.html
|components=Core::Internationalization
}}

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

{{Module
|name=IPC
|description=Native message-passing between threads and processes
|owner=[mailto:jld@mozilla.com Jed Davis]
|ownersemeritus=Chris Jones, Bill McCloskey
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

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

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

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

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

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

{{Module
|name=Layout Engine
|description=rendering tree construction, layout (reflow), etc.
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:emilio@crisal.io Emilio Cobos Álvarez]
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/
|url=https://wiki.mozilla.org/Gecko:Overview#Layout
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Columns, Core::Layout: Flexbox, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: Generated Content, Lists, and Counters, Core::Layout: Grid, Core::Layout: Images, Video, and HTML Frames, Core::Layout: Positioned, Core::Layout: Ruby, Core::Layout: Scrolling and Overflow, Core::Layout: Tables, Core::Layout: Text and Fonts, Core::Print Preview, Core::Printing: Output
}}

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

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

{{Module
|name=Media Playback
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]
|group=dev-media
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/
|url=
|components=Core::Audio/Video
}}

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

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

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

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

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

{{Module
|name=MSCOM
|description=Integration with Microsoft Distributed COM
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]
|group=dev-platform
|source_dirs=ipc/mscom/%
|url=
|components=Core::IPC: MSCOM}}

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

{{Module
|name=NodeJS usage, tools, and style
|description=Advises on the use of NodeJS and npm packages at build and runtime. Reviews additions/upgrades/removals of vendored npm packages. Works with appropriate teams to maintain automated license and security audits of npm packages. Works with the security team and relevant developers to respond to vulnerabilities in NodeJS and vendored npm packages.
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]
|peers=[mailto:mbanner@mozilla.com Mark Banner], [mailto:dcoates@mozilla.com Danny Coates], [mailto:khudson@mozilla.com Kate Hudson], [mailto:jlaster@mozilla.com Jason Laster], [mailto:elee@mozilla.com Ed Lee], [mailto:dtownsend@mozilla.com Dave Townsend]
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate
|components=Various components
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack
}}

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

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

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

{{Module
|name=Preferences
|description=Preference library
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm], [mailto:kwright@mozilla.com Kristen Wright]
|peersemeritus=Felipe Gomes
|group=dev-platform
|source_dirs=modules/libpref/
|url=
|components=Core::Preferences: Backend
}}

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

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

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

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:dueno@redhat.com Daiki Ueno]
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM
}}

{{Module
|name=Static analysis & rewriting for C++
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:eakhgari@mozilla.com Ehsan Akhgari]
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]
|group=dev-platform
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools
|url=
|components=Core::Rewriting & Analysis
}}
{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner=[mailto:cam@mcc.id.au Cameron McCormack]
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/style/, servo/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:mstange@themasta.com Markus Stange]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:padenot@mozilla.com Paul Adenot]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=Web Painting
|description=painting, display lists, and layer construction
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]
|group=dev-tech-layout
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses
|url=http://mozilla.org/newlayout/doc/ ,
http://lxr.mozilla.org/mozilla/source/layout/doc/
|components=Core::Layout: Web Painting
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC, Core::WebRTC Networking
}}

{{Module
|name=WebVR
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=dom/vr, gfx/vr
|url=https://mozvr.com/
|components=Core::WebVR
}}

{{Module
|name=Widget
|description=Top level Widget
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter],
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup
}}

{{Module
|name=Widget - Android
|description=Android widget support
|owner=[mailto:jwillcox@mozilla.com James Willcox]
|peers=
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=GTK widget support
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]
|peers=[mailto:stransky@redhat.com Martin Stránský]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - Headless
|description=Headless widget support
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]
|peers=
|ownersemeritus=
|group=dev-platform
|source_dirs=widget/headless/
|url=
|components=Firefox::Headless
}}

{{Module
|name=Widget - macOS
|description= macOS widget support
|owner=[mailto:spohl@mozilla.com Stephen A Pohl]
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:haftandilian@mozilla.com Haik Aftandilian]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widget support
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:aklotz@mozilla.com Aaron Klotz]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|peers=[mailto:erahm@mozilla.com Eric Rahm], [mailto:nika@thelayzells.com Nika Layzell], [mailto:kmaglione@mozilla.com Kris Maglione]
|ownersemeritus=Benjamin Smedberg
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:nika@thelayzells.com Nika Layzell]
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]
|peers=
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux
|description=Sandboxing for the Linux platform
|owner=[mailto:jld@mozilla.com Jed Davis]
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Crash reporting
|description=Infrastructure and tools used to generate, submit and process crash reports. This includes the in-tree google-breakpad fork, the crash report generation machinery as well as the host tools used to dump symbols, analyse minidumps and generate stack traces.
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj)
|group=dev-platform
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html
|components=Toolkit::Crash Reporting
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]
|peers=Same as Build Config
|group=dev-builds
|components=Core::Build Config
}}

{{Module
|name=Build Config - Taskgraph
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.
|owner=[mailto:mozilla@hocat.ca Tom Prince]
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:dustin@mozilla.com Dustin Mitchell]
|components=Firefox Build System::Task Configuration
}}

{{Module
|name=WebRTC Media
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson],
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Audio/Video)
}}

{{Module
|name=WebRTC Signaling
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling
|owner=[mailto:bcampen@mozilla.com Byron Campen]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc/signaling/
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Signaling)
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::Find Backend
Core::General
Core::History: Global
Core::Image Blocking
Core::Localization
Core::Networking: Domain Lists
Core::Selection
Core::Serializers
Core::Spelling checker
Core::X-remote
Core::XUL
</pre>
</noinclude>

Oxidation

2019-06-19T18:01:30Z

Jorend: /* Proposed */ why rust

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

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

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

= Guidelines =

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

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

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

== Rust Strengths ==

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

== Rust Weaknesses ==

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

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

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

== Recommendations ==

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

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

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

= Documentation and assistance =

== Rust in general ==

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

== Rust in Firefox ==

* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.
** Alexis Beingessner (:gankro)
** Josh Bowman-Matthews (:jdm)
** Emilio Cobos Alvarez (:emilio)
** Manish Goregaokar (:manishearth)
** Nika Layzell (:mystor)
** Cameron McCormack (:heycam)

= Rust Components =

== Within Firefox ==

=== Shipped ===

* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.

=== In progress ===

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

=== Proposed ===

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

== Outside Firefox ==

=== Completed ===

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

=== In Progress ===

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

= Blockers and obstacles =

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

= Meetings =

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

JavaScript:Bugzilla

2019-06-13T19:32:38Z

Jorend: /* Triage */ fmt

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off the following lists:

* '''[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine%3A+JIT&component=JavaScript%3A+GC&component=JavaScript%3A+Internationalization+API&component=JavaScript%3A+Standard+Library&component=Javascript%3A+WebAssembly&component=js-ctypes&owner= List of non-prioritized bugs]''' - This list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes needinfo? people.

* '''[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet]''' - Scroll down to the bottom, under "Pending Untriaged (defects only)". This reports per-component the number of bugs which need to be triaged.

* '''[https://wiki.mozilla.org/Platform#Bug_Lists Regressions]''' - The queries there are used by the regression triage meeting. [https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=SpiderMonkey-Regression-67-68-69&sharer_id=607698&list_id=14761639 Convenient summary query for 67-68-69 regressions]

* '''[https://bugzilla.mozilla.org/buglist.cgi?keywords=sec-critical%2Csec-high&keywords_type=anywords&o2=notsubstring&v2=stalled&resolution=---&query_format=advanced&f2=keywords&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&product=Core&list_id=14762036 Security bugs]''' - Also, [https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&f2=keywords&f3=bug_group&o2=notsubstring&o3=anywords&product=Core&resolution=---&v2=stalled&v3=javascript-core-security&list_id=14673658 this query] is the same but not limited to sec-high and sec-critical bugs

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-03-18&f4=cf_status_firefox67&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox67&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx67 List of P1 affecting Firefox 67]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

JavaScript:Bugzilla

2019-06-13T19:32:23Z

Jorend: /* Triage */ 25

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off the following lists:

* '''[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine%3A+JIT&component=JavaScript%3A+GC&component=JavaScript%3A+Internationalization+API&component=JavaScript%3A+Standard+Library&component=Javascript%3A+WebAssembly&component=js-ctypes&owner= List of non-prioritized bugs]''' - This list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes needinfo? people.

* '''[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet]''' - Scroll down to the bottom, under "Pending Untriaged (defects only)". This reports per-component the number of bugs which need to be triaged.

* '''[https://wiki.mozilla.org/Platform#Bug_Lists Regressions]''' - The queries there are used by the regression triage meeting. [https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=SpiderMonkey-Regression-67-68-69&sharer_id=607698&list_id=14761639 Convenient summary query for 67-68-69 regressions]

* '''[https://bugzilla.mozilla.org/buglist.cgi?keywords=sec-critical%2Csec-high&keywords_type=anywords&o2=notsubstring&v2=stalled&resolution=---&query_format=advanced&f2=keywords&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&product=Core&list_id=14762036 Security bugs]``` - Also, [https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&f2=keywords&f3=bug_group&o2=notsubstring&o3=anywords&product=Core&resolution=---&v2=stalled&v3=javascript-core-security&list_id=14673658 this query] is the same but not limited to sec-high and sec-critical bugs

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-03-18&f4=cf_status_firefox67&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox67&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx67 List of P1 affecting Firefox 67]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

JavaScript:Bugzilla

2019-06-13T15:33:18Z

Jorend: /* Triage */ clarify link is version-specific

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off the following lists:

* '''[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine%3A+JIT&component=JavaScript%3A+GC&component=JavaScript%3A+Internationalization+API&component=JavaScript%3A+Standard+Library&component=Javascript%3A+WebAssembly&component=js-ctypes&owner= List of non-prioritized bugs]''' - This list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes needinfo? people.

* '''[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet]''' - Scroll down to the bottom, under "Pending Untriaged (defects only)". This reports per-component the number of bugs which need to be triaged.

* '''[https://wiki.mozilla.org/Platform#Bug_Lists Regressions]''' - The queries there are used by the regression triage meeting. [https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=SpiderMonkey-Regression-67-68-69&sharer_id=607698&list_id=14761639 Convenient summary query for 67-68-69 regressions]

* '''[https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&f2=keywords&f3=bug_group&o2=notsubstring&o3=anywords&product=Core&resolution=---&v2=stalled&v3=javascript-core-security&list_id=14673658 Security bugs]'''

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-03-18&f4=cf_status_firefox67&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox67&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx67 List of P1 affecting Firefox 67]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

JavaScript:Bugzilla

2019-06-13T15:32:46Z

Jorend: /* Triage */ add sdetar's regression query

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off the following lists:

* '''[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine%3A+JIT&component=JavaScript%3A+GC&component=JavaScript%3A+Internationalization+API&component=JavaScript%3A+Standard+Library&component=Javascript%3A+WebAssembly&component=js-ctypes&owner= List of non-prioritized bugs]''' - This list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes needinfo? people.

* '''[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet]''' - Scroll down to the bottom, under "Pending Untriaged (defects only)". This reports per-component the number of bugs which need to be triaged.

* '''[https://wiki.mozilla.org/Platform#Bug_Lists Regressions]''' - The queries there are used by the regression triage meeting. [https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=SpiderMonkey-Regression-67-68-69&sharer_id=607698&list_id=14761639 Convenient summary query]

* '''[https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&f2=keywords&f3=bug_group&o2=notsubstring&o3=anywords&product=Core&resolution=---&v2=stalled&v3=javascript-core-security&list_id=14673658 Security bugs]'''

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-03-18&f4=cf_status_firefox67&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox67&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx67 List of P1 affecting Firefox 67]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

JavaScript:Bugzilla

2019-04-18T15:48:05Z

Jorend: /* Triage */ wefgrwaef

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off the following lists:

* '''[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine%3A+JIT&component=JavaScript%3A+GC&component=JavaScript%3A+Internationalization+API&component=JavaScript%3A+Standard+Library&component=Javascript%3A+WebAssembly&component=js-ctypes&owner= List of non-prioritized bugs]''' - This list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes needinfo? people.

* '''[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet]''' - Scroll down to the bottom, under "Pending Untriaged (defects only)". This reports per-component the number of bugs which need to be triaged.

* '''[https://wiki.mozilla.org/Platform#Bug_Lists Regressions]''' - The queries there are used by the regression triage meeting.

* '''[https://bugzilla.mozilla.org/buglist.cgi?keywords=sec-high%2C%20sec-critical%2C%20&keywords_type=anywords&list_id=14673624&v11=stalled&f10=CP&f8=CP&o11=notsubstring&columnlist=component%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Cstatus_whiteboard%2Ckeywords%2Cbug_type%2Cflagtypes.name%2Cpriority&resolution=---&query_format=advanced&f3=OP&f11=keywords&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&product=Core Security bugs]'''

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-03-18&f4=cf_status_firefox67&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox67&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx67 List of P1 affecting Firefox 67]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

JavaScript:Bugzilla

2019-04-18T15:47:29Z

Jorend: /* Triage */ waefgaregserthergwe

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off the following lists:

* '''[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine%3A+JIT&component=JavaScript%3A+GC&component=JavaScript%3A+Internationalization+API&component=JavaScript%3A+Standard+Library&component=Javascript%3A+WebAssembly&component=js-ctypes&owner= List of non-prioritized bugs]''' - This list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes needinfo? people.

* '''[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet]''' - Scroll down to the bottom. This reports per-component the number of bugs which need to be triaged.

* '''[https://wiki.mozilla.org/Platform#Bug_Lists Regressions]''' - The queries there are used by the regression triage meeting.

* '''[https://bugzilla.mozilla.org/buglist.cgi?keywords=sec-high%2C%20sec-critical%2C%20&keywords_type=anywords&list_id=14673624&v11=stalled&f10=CP&f8=CP&o11=notsubstring&columnlist=component%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Cstatus_whiteboard%2Ckeywords%2Cbug_type%2Cflagtypes.name%2Cpriority&resolution=---&query_format=advanced&f3=OP&f11=keywords&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&product=Core Security bugs]'''

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-03-18&f4=cf_status_firefox67&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox67&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx67 List of P1 affecting Firefox 67]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

JavaScript:Bugzilla

2019-04-18T15:41:49Z

Jorend: /* Triage */ waefawijefiwajue

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off this list:

[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine%3A+JIT&component=JavaScript%3A+GC&component=JavaScript%3A+Internationalization+API&component=JavaScript%3A+Standard+Library&component=Javascript%3A+WebAssembly&component=js-ctypes&owner= List of non-prioritized bugs]

The list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes requesting feedback from other members of the team.

=== Are we triaged yet? ===

[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet] is currently used as a dashboard for reporting per-component the number of bugs which needs to be given priorities, or status flags.

=== Regressions ===

The queries listed here are used by the regression triage meeting: https://wiki.mozilla.org/Platform#Bug_Lists

=== Security bugs ===

[https://bugzilla.mozilla.org/buglist.cgi?keywords=sec-high%2C%20sec-critical%2C%20&keywords_type=anywords&list_id=14673624&v11=stalled&f10=CP&f8=CP&o11=notsubstring&columnlist=component%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Cstatus_whiteboard%2Ckeywords%2Cbug_type%2Cflagtypes.name%2Cpriority&resolution=---&query_format=advanced&f3=OP&f11=keywords&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&product=Core Security bugs]

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-03-18&f4=cf_status_firefox67&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox67&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx67 List of P1 affecting Firefox 67]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

JavaScript:Bugzilla

2019-04-18T15:26:08Z

Jorend: /* Triage */ awuierhwauiejjugser

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off this list:

[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine%3A+JIT&component=JavaScript%3A+GC&component=JavaScript%3A+Internationalization+API&component=JavaScript%3A+Standard+Library&component=Javascript%3A+WebAssembly&component=js-ctypes&owner= List of non-prioritized bugs]

The list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes requesting feedback from other members of the team.

=== Are we triaged yet? ===

[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet] is currently used as a dashboard for reporting per-component the number of bugs which needs to be given priorities, or status flags.

=== Regressions ===

The New Bugs list linked here is used.

https://wiki.mozilla.org/Platform#Bug_Lists

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-03-18&f4=cf_status_firefox67&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox67&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx67 List of P1 affecting Firefox 67]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=sec-critical%2Csec-high%2C&keywords_type=anywords&resolution=---&o2=notsubstring&query_format=advanced&f2=keywords&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A10%3A12%20AM%20GC&v2=stalled&product=Core&list_id=14673529 Security bugs]

JavaScript:Bugzilla

2019-04-18T15:17:21Z

Jorend: awjuiojpawiewsaefj

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off this list:

[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine%3A+JIT&component=JavaScript%3A+GC&component=JavaScript%3A+Internationalization+API&component=JavaScript%3A+Standard+Library&component=Javascript%3A+WebAssembly&component=js-ctypes&owner= List of non-prioritized bugs]

The list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes requesting feedback from other members of the team.

=== Are we triaged yet? ===

[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet] is currently used as a dashboard for reporting per-component the number of bugs which needs to be given priorities, or status flags.

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-03-18&f4=cf_status_firefox67&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox67&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx67 List of P1 affecting Firefox 67]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=sec-critical%2Csec-high%2C&keywords_type=anywords&resolution=---&o2=notsubstring&query_format=advanced&f2=keywords&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A10%3A12%20AM%20GC&v2=stalled&product=Core&list_id=14673529 Security bugs]

JavaScript:Bugzilla

2019-03-29T15:08:45Z

Jorend: /* P1 re-triage */ add a link for P1 FF67

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off this list:

[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine%3A+JIT&component=JavaScript%3A+GC&component=JavaScript%3A+Internationalization+API&component=JavaScript%3A+Standard+Library&component=Javascript%3A+WebAssembly&component=js-ctypes&owner= List of non-prioritized bugs]

The list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes requesting feedback from other members of the team.

=== Are we triaged yet? ===

[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet] is currently used as a dashboard for reporting per-component the number of bugs which needs to be given priorities, or status flags.

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-03-18&f4=cf_status_firefox67&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox67&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx67 List of P1 affecting Firefox 67]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

JavaScript:Bugzilla

2019-02-21T16:10:39Z

Jorend: /* Triage */ fix broken link better

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off this list:

[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine%3A+JIT&component=JavaScript%3A+GC&component=JavaScript%3A+Internationalization+API&component=JavaScript%3A+Standard+Library&component=Javascript%3A+WebAssembly&component=js-ctypes&owner= List of non-prioritized bugs]

The list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes requesting feedback from other members of the team.

=== Are we triaged yet? ===

[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet] is currently used as a dashboard for reporting per-component the number of bugs which needs to be given priorities, or status flags.

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

JavaScript:Bugzilla

2019-02-21T16:00:01Z

Jorend: /* Triage */ fix broken link

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off this list:

[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine:+JIT&component=JavaScript:+GC&component=JavaScript:+Internationalization+API&component=JavaScript:+Standard+Library&component=js-ctypes&owner= List of non-prioritized bugs]

The list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes requesting feedback from other members of the team.

=== Are we triaged yet? ===

[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet] is currently used as a dashboard for reporting per-component the number of bugs which needs to be given priorities, or status flags.

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2019-01-28&f4=cf_status_firefox66&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox66&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx66 List of P1 affecting Firefox 66]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

JavaScript:Bugzilla

2018-12-13T16:08:26Z

Jorend: /* Triage */ make list link more prominent

This page explains how the JavaScript Team uses [https://bugzilla.mozilla.org Bugzilla].

== Bugzilla components ==

* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine Core::JavaScript Engine]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20JIT#JavaScript%20Engine Core::JavaScript Engine: JIT]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20GC#JavaScript%20Engine Core::JavaScript: GC]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Internationalization%20API#JavaScript%20Engine Core::JavaScript: Internationalization API]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine:%20Standard%20Library#JavaScript%20Engine Core::JavaScript: Standard Library]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=Javascript:%20Web%20Assembly#Javascript:%20Web%20Assembly Core::Java'''''s'''''cript: Web Assembly]
* [https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=js-ctypes#JavaScript%20Engine Core::js-ctypes]

== Review flags ==

The JS team uses the review flags the same way as the rest of Gecko developer. The only difference is the lack of "r-" when a review needs to be revisited, instead the review request is canceled with comments. The "r-" flag is used only in a few cases where multiple reviewers are requested on the same patch, and one of them is opposed to the changes.

== Whiteboard flags ==

A few whiteboard flags are used today in the JS components:

* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5B%23jsapi%3Acrashes-retriage%5D&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=%23jsapi:crashes-retriage [#jsapi:crashes-retriage<nowiki>]</nowiki>] Used for crash-stat crashes which might be harder to investigate alone. This whiteboard tag is used to cluster the analysis of crash-stat reports. (Owner: Ted Campbell)
* [qf] Used for any performance regression/improvement which can be part of the Quantum Flow effort of fixing known bugs. (Owner: Kannan Vijayan) These bugs are later sorted by the performance team into [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap1&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&list_id=14434361&title=qf%20p1 [qf:p1<nowiki>]</nowiki>], [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap2&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p2 [qf:p2<nowiki>]</nowiki>] and [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bqf%3Ap3&resolution=---&query_format=advanced&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=Javascript%3A%20Web%20Assembly&component=js-ctypes&product=Core&title=qf%20p3 [qf:p3<nowiki>]</nowiki>]
* [arm64:m...] Used to track [https://wiki.mozilla.org/Mobile/ARM64 milestone blocker bugs for ARM64 Fennec and GeckoView].
* [lang={c++,py,js}] Is used in tandem with the [[Good_first_bug#Good_First_Bugs|good-first-bugs]] keyword to list this bug as in [[BugsAhoy|BugsAhoy!]].

As a convention, anybody can follow the following naming for using the whiteboard to improve Bugzilla searches. However, note that whiteboard searches are not indexed in Bugzilla databases and this might lead to performance issues.

* [:nick:...] Used by the user :nick for managing bugs.
* [#channel:...] Used by members of the IRC #channel for managing bugs.

== Priority Flags ==

Priority flags are set based on the current goals. The list of goals can be found in the JS Team document which list all the goals.
The addon [https://addons.mozilla.org/en-US/firefox/addon/bugzilla-triage-helper/ bugzilla triage helper] can be used to set the P1, P2, P3 and P5 (no P4) flags

* P1: P1 goals or blockers, Security issues. (to be fixed ASAP)
* P2: P2 goals or blockers. (scheduled to be fixed in an upcoming version)
* P3: P3 goals or blockers. (backlog; to be fixed one day)
* P5: (not a priority for Firefox product; might never be fixed)

== Triage ==

The triage effort is currently held by the triage owners, and supported by Jason Orendorff and Nicolas B. Pierron. They mainly work off this list:

[https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html&product=Core&component=JavaScript+Engine&component=JavaScript+Engine:+JIT&component=JavaScript:+GC&component=JavaScript:+Internationalization+API&component=JavaScript:+Standard+Library&component=js-ctypes&component=Javascript%3A+Web+Assembly&owner= List of non-prioritized bugs]

The list is used to set the missing priority flags and whiteboard flags to the corresponding bugs and sometimes requesting feedback from other members of the team.

=== Are we triaged yet? ===

[https://are-we-triaged-yet.herokuapp.com/ Are We Triaged Yet] is currently used as a dashboard for reporting per-component the number of bugs which needs to be given priorities, or status flags.

=== P1 re-triage ===

A weekly meeting is held every Thursday to re-triage P1 which have seen no activity for a while. The following searches are lists of non-meta and non-stalled P1 issues affecting Firefox VV.

In this case affecting means: status-firefoxVV == affected || (status-firefoxVV is-empty && creation-date <= [[Release Management/Calendar|betaVV-merge-date]]).
To avoid re-iterating over iterating every weeks over the same bugs, we filter out bugs which have been changed in the last 10 days.

* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-12-10&f4=cf_status_firefox65&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox65&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx65 List of P1 affecting Firefox 65]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-10-22&f4=cf_status_firefox64&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox64&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx64 List of P1 affecting Firefox 64]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-09-04&f4=cf_status_firefox63&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox63&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx63 List of P1 affecting Firefox 63]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164358&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-06-25&f4=cf_status_firefox62&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox62&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx62 List of P1 affecting Firefox 62]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164352&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-05-07&f4=cf_status_firefox61&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox61&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx61 List of P1 affecting Firefox 61]
* [https://bugzilla.mozilla.org/buglist.cgi?keywords=meta%2C%20stalled&keywords_type=nowords&list_id=14164353&o1=notequals&o2=notregexp&o4=equals&j3=OR&v1=enhancement&v2=%5E%5C%5Bmeta&priority=P1&v4=affected&f10=CP&f1=bug_severity&o7=lessthaneq&f8=CP&resolution=---&o6=isempty&v7=2018-03-12&f4=cf_status_firefox60&query_format=advanced&f3=OP&f2=short_desc&f5=OP&component=JavaScript%20Engine&component=JavaScript%20Engine%3A%20JIT&component=JavaScript%3A%20GC&component=JavaScript%3A%20Internationalization%20API&component=JavaScript%3A%20Standard%20Library&component=js-ctypes&component=Javascript%3A%20Web%20Assembly&f6=cf_status_firefox60&product=Core&f7=creation_ts&v11=10&o11=greaterthan&f11=days_elapsed&title=P1%20Fx60 List of P1 affecting Firefox 60]

Modules/Core

2018-10-17T11:40:10Z

Jorend: fmt

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

They may:

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

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

{{Module
|name=Animation
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)
|group=dev-tech-layout
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko
|components=Core::DOM::Animation, Core::CSS Parsing and Computation (for CSS animations/transitions related bugs)
}}

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

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

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

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

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

{{Module
|name=Content Security
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]
|peers=[mailto:francois@mozilla.com François Marier], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston]
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-security
|source_dirs=dom/security
|components=Core::DOM: Security
}}

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

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

{{Module
|name=DOM File
|description=DOM Blob, File and FileSystem APIs
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:olli@pettay.fi Olli Pettay]
|group=dev-platform
|source_dirs=dom/file, dom/filesystem
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM: File
}}

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

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

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

{{Module
|name=Editor
|description=
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

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

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

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

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

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

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

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

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

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

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

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

{{Module
|name=I18N Library
|description=
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]
|group=dev-i18n
|source_dirs=intl/
|url=http://mozilla.org/projects/intl/index.html
|components=Core::Internationalization
}}

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

{{Module
|name=IPC
|description=Native message-passing between threads and processes
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:jld@mozilla.com Jed Davis], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:amccreight@mozilla.com Andrew McCreight]
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:danderson@mozilla.com David Anderson], [mailto:kchen@mozilla.com Kan-Ru Chen], [mailto:btseng@mozilla.com Bevis Tseng]
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

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

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

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

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

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

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

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

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

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

{{Module
|name=Media Playback
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]
|group=dev-media
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/
|url=
|components=Core::Audio/Video
}}

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

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

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

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

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

{{Module
|name=MSCOM
|description=Integration with Microsoft Distributed COM
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]
|group=dev-platform
|source_dirs=ipc/mscom/%
|url=
|components=Core::IPC: MSCOM}}

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

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

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

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

{{Module
|name=Preferences
|description=Preference library
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:felipe@mozilla.com Felipe Gomes], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-platform
|source_dirs=modules/libpref/
|url=
|components=Core::Preferences: Backend
}}

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

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

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

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

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

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:martin.thomson@gmail.com Martin Thomson]
|ownersemeritus=[mailto:ttaubert@mozilla.com Tim Taubert]
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:wtc@google.com Wan-Teh Chang], [mailto:dueno@redhat.com Daiki Ueno]
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM
}}

{{Module
|name=Static analysis & rewriting for C++
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.
|owner=[mailto:nika@thelayzells.com Nika Layzell] (while Ehsan is away)
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:andi@mozilla.com Andi-Bogdan Postelnicu]
|group=dev-platform
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools
|url=
|components=Core::Rewriting & Analysis
}}
{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner= [mailto:cam@mcc.id.au Cameron McCormack]
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/style/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=Tamarin
|description=VM for ActionScript and JavaScript
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]
|group=dev-tech-js-engine
|source_dirs=js/tamarin
|url=http://www.mozilla.org/projects/tamarin/
http://wiki.mozilla.org/tamarin/
http://hg.mozilla.org/tamarin-central/
http://hg.mozilla.org/tamarin-tracing/
|components=Tamarin
}}

{{Module
|name=Test Harness
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill, Marionette, Firefox UI Tests. Requests for new harnesses should go to Testing::General.
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), Rob Campbell (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (Marionette, Firefox UI tests), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette), [mailto:dminor@mozilla.com Dan Minor], [mailto:mjzffr@gmail.com Maja Frydrychowicz] (Marionette, Firefox UI tests),

|group=dev-quality
|source_dirs=/testing
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js
}}

{{Module
|name=Testing Infrastructure
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker
|owner=[mailto:jmaher@mozilla.com Joel Maher]
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], Rob Campbell, [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]
|group=dev-quality
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::Infrastructure
}}

{{Module
|name=JS Marionette
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye>
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk>
|source_dirs=gaia/tests/jsmarionette
|components=Testing::JSMarionette
|group=dev-gaia
}}

{{Module
|name=XPCShell Test Harness
|description=The XPCShell Harness
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]
|peers=[mailto:jmaher@mozilla.com Joel Maher]
|source_dirs=testing/xpcshell
|components=Testing::XPCShell Harness
}}

{{Module
|name=Update Service
|description=server code for Mozilla Update services (aus, addons, pfs)
|owner=Mike Morgan
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]
|group=dev-amo
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/
|url=http://wiki.mozilla.org/wiki/AMO
|components=AUS::Administration, AUS::Systems
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:mstange@themasta.com Markus Stange]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:padenot@mozilla.com Paul Adenot]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=Web Painting
|description=painting, display lists, and layer construction
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]
|group=dev-tech-layout
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses
|url=http://mozilla.org/newlayout/doc/ ,
http://lxr.mozilla.org/mozilla/source/layout/doc/
|components=Core::Layout: Web Painting
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC, Core::WebRTC Networking
}}

{{Module
|name=WebVR
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration
|owner=[mailto:kgilbert@mozilla.com Kip Gilbert]
|peers=[mailto:dmu@mozilla.com Daosheng Mu]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=dom/vr, gfx/vr
|url=https://mozvr.com/
|components=Core::WebVR
}}

{{Module
|name=Widget
|description=
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter],
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup
}}

{{Module
|name=Widget - Android
|description=The Android Port
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]
|peers=[mailto:jwillcox@mozilla.com James Willcox]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=supported X widgetry and gfx
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - OS X
|description= Gecko's OS X compatibility layer.
|owner=[mailto:mstange@themasta.com Markus Stange]
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widgets and desktop integration
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:jmathies@mozilla.com Jim Mathies]
|peersemeritus=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XBL
|description=eXtensible Binding Language
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xbl
|source_dirs=dom/xbl/
|url=http://www.mozilla.org/projects/xbl/
|components=Core::XBL
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|peers=[mailto:erahm@mozilla.com Eric Rahm]
|ownersemeritus=Benjamin Smedberg
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:me@kylehuey.com Kyle Huey]
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XPInstall
|description=
|owner=[mailto:dveditz@mozilla.com Dan Veditz]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|group=dev-tech-xpinstall
|source_dirs=xpinstall/
|url=
|components=Core::Installer: XPInstall Engine
}}

{{Module
|name=XPToolkit
|description=Cross-platform user interface toolkit
|owner=
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]
|group=dev-tech-xul
|source_dirs=dom/xul/, layout/xul/
|url=http://www.mozilla.org/xpfe/
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]
|peers=
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux
|description=Sandboxing for the Linux platform
|owner=[mailto:jld@mozilla.com Jed Davis]
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]
|peers=Same as Build Config
|group=dev-builds
|components=Core::Build Config
}}

{{Module
|name=Build Config - Taskgraph
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.
|owner=[mailto:dustin@mozilla.com Dustin Mitchell]
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:mozilla@hocat.ca Tom Prince]
|components=Firefox Build System::Task Configuration
}}

{{Module
|name=WebRTC Media
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson],
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Audio/Video)
}}

{{Module
|name=WebRTC Signaling
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling
|owner=[mailto:bcampen@mozilla.com Byron Campen]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc/signaling/
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Signaling)
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::Find Backend
Core::General
Core::HTML: Form Submission
Core::History: Global
Core::Image Blocking
Core::Localization
Core::Networking: Domain Lists
Core::Selection
Core::Serializers
Core::Spelling checker
Core::X-remote
Core::XUL
</pre>
</noinclude>

Modules/Core

2018-10-17T11:38:22Z

Jorend: JS peers: add sfink, khyperia, anba, jonco

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

They may:

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

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

{{Module
|name=Animation
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)
|group=dev-tech-layout
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko
|components=Core::DOM::Animation, Core::CSS Parsing and Computation (for CSS animations/transitions related bugs)
}}

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

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

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

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

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

{{Module
|name=Content Security
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]
|peers=[mailto:francois@mozilla.com François Marier], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston]
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-security
|source_dirs=dom/security
|components=Core::DOM: Security
}}

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

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

{{Module
|name=DOM File
|description=DOM Blob, File and FileSystem APIs
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:olli@pettay.fi Olli Pettay]
|group=dev-platform
|source_dirs=dom/file, dom/filesystem
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM: File
}}

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

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

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

{{Module
|name=Editor
|description=
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

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

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

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

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

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

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

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

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

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

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

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

{{Module
|name=I18N Library
|description=
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]
|group=dev-i18n
|source_dirs=intl/
|url=http://mozilla.org/projects/intl/index.html
|components=Core::Internationalization
}}

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

{{Module
|name=IPC
|description=Native message-passing between threads and processes
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:jld@mozilla.com Jed Davis], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:amccreight@mozilla.com Andrew McCreight]
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:danderson@mozilla.com David Anderson], [mailto:kchen@mozilla.com Kan-Ru Chen], [mailto:btseng@mozilla.com Bevis Tseng]
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

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

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

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

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

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

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

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

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

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

{{Module
|name=Media Playback
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]
|group=dev-media
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/
|url=
|components=Core::Audio/Video
}}

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

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

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

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

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

{{Module
|name=MSCOM
|description=Integration with Microsoft Distributed COM
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]
|group=dev-platform
|source_dirs=ipc/mscom/%
|url=
|components=Core::IPC: MSCOM}}

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

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

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

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

{{Module
|name=Preferences
|description=Preference library
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:felipe@mozilla.com Felipe Gomes], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-platform
|source_dirs=modules/libpref/
|url=
|components=Core::Preferences: Backend
}}

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

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

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

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

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

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:martin.thomson@gmail.com Martin Thomson]
|ownersemeritus=[mailto:ttaubert@mozilla.com Tim Taubert]
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:wtc@google.com Wan-Teh Chang], [mailto:dueno@redhat.com Daiki Ueno]
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM
}}

{{Module
|name=Static analysis & rewriting for C++
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.
|owner=[mailto:nika@thelayzells.com Nika Layzell] (while Ehsan is away)
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:andi@mozilla.com Andi-Bogdan Postelnicu]
|group=dev-platform
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools
|url=
|components=Core::Rewriting & Analysis
}}
{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner= [mailto:cam@mcc.id.au Cameron McCormack]
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/style/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=Tamarin
|description=VM for ActionScript and JavaScript
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]
|group=dev-tech-js-engine
|source_dirs=js/tamarin
|url=http://www.mozilla.org/projects/tamarin/
http://wiki.mozilla.org/tamarin/
http://hg.mozilla.org/tamarin-central/
http://hg.mozilla.org/tamarin-tracing/
|components=Tamarin
}}

{{Module
|name=Test Harness
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill, Marionette, Firefox UI Tests. Requests for new harnesses should go to Testing::General.
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), Rob Campbell (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (Marionette, Firefox UI tests), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette), [mailto:dminor@mozilla.com Dan Minor], [mailto:mjzffr@gmail.com Maja Frydrychowicz] (Marionette, Firefox UI tests),

|group=dev-quality
|source_dirs=/testing
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js
}}

{{Module
|name=Testing Infrastructure
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker
|owner=[mailto:jmaher@mozilla.com Joel Maher]
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], Rob Campbell, [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]
|group=dev-quality
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::Infrastructure
}}

{{Module
|name=JS Marionette
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye>
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk>
|source_dirs=gaia/tests/jsmarionette
|components=Testing::JSMarionette
|group=dev-gaia
}}

{{Module
|name=XPCShell Test Harness
|description=The XPCShell Harness
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]
|peers=[mailto:jmaher@mozilla.com Joel Maher]
|source_dirs=testing/xpcshell
|components=Testing::XPCShell Harness
}}

{{Module
|name=Update Service
|description=server code for Mozilla Update services (aus, addons, pfs)
|owner=Mike Morgan
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]
|group=dev-amo
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/
|url=http://wiki.mozilla.org/wiki/AMO
|components=AUS::Administration, AUS::Systems
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:mstange@themasta.com Markus Stange]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:padenot@mozilla.com Paul Adenot]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=Web Painting
|description=painting, display lists, and layer construction
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]
|group=dev-tech-layout
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses
|url=http://mozilla.org/newlayout/doc/ ,
http://lxr.mozilla.org/mozilla/source/layout/doc/
|components=Core::Layout: Web Painting
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC, Core::WebRTC Networking
}}

{{Module
|name=WebVR
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration
|owner=[mailto:kgilbert@mozilla.com Kip Gilbert]
|peers=[mailto:dmu@mozilla.com Daosheng Mu]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=dom/vr, gfx/vr
|url=https://mozvr.com/
|components=Core::WebVR
}}

{{Module
|name=Widget
|description=
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter],
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup
}}

{{Module
|name=Widget - Android
|description=The Android Port
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]
|peers=[mailto:jwillcox@mozilla.com James Willcox]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=supported X widgetry and gfx
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - OS X
|description= Gecko's OS X compatibility layer.
|owner=[mailto:mstange@themasta.com Markus Stange]
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widgets and desktop integration
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:jmathies@mozilla.com Jim Mathies]
|peersemeritus=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XBL
|description=eXtensible Binding Language
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xbl
|source_dirs=dom/xbl/
|url=http://www.mozilla.org/projects/xbl/
|components=Core::XBL
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|peers=[mailto:erahm@mozilla.com Eric Rahm]
|ownersemeritus=Benjamin Smedberg
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:me@kylehuey.com Kyle Huey]
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XPInstall
|description=
|owner=[mailto:dveditz@mozilla.com Dan Veditz]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|group=dev-tech-xpinstall
|source_dirs=xpinstall/
|url=
|components=Core::Installer: XPInstall Engine
}}

{{Module
|name=XPToolkit
|description=Cross-platform user interface toolkit
|owner=
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]
|group=dev-tech-xul
|source_dirs=dom/xul/, layout/xul/
|url=http://www.mozilla.org/xpfe/
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]
|peers=
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux
|description=Sandboxing for the Linux platform
|owner=[mailto:jld@mozilla.com Jed Davis]
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]
|peers=Same as Build Config
|group=dev-builds
|components=Core::Build Config
}}

{{Module
|name=Build Config - Taskgraph
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.
|owner=[mailto:dustin@mozilla.com Dustin Mitchell]
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:mozilla@hocat.ca Tom Prince]
|components=Firefox Build System::Task Configuration
}}

{{Module
|name=WebRTC Media
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson],
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Audio/Video)
}}

{{Module
|name=WebRTC Signaling
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling
|owner=[mailto:bcampen@mozilla.com Byron Campen]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc/signaling/
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Signaling)
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::Find Backend
Core::General
Core::HTML: Form Submission
Core::History: Global
Core::Image Blocking
Core::Localization
Core::Networking: Domain Lists
Core::Selection
Core::Serializers
Core::Spelling checker
Core::X-remote
Core::XUL
</pre>
</noinclude>

Modules/Core

2018-10-17T11:25:45Z

Jorend: move a bunch of JS peers to emeritus; add Ted Campbell

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

They may:

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

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

{{Module
|name=Animation
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)
|group=dev-tech-layout
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko
|components=Core::DOM::Animation, Core::CSS Parsing and Computation (for CSS animations/transitions related bugs)
}}

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

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

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

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

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

{{Module
|name=Content Security
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]
|peers=[mailto:francois@mozilla.com François Marier], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston]
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-security
|source_dirs=dom/security
|components=Core::DOM: Security
}}

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

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

{{Module
|name=DOM File
|description=DOM Blob, File and FileSystem APIs
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]
|peers=[mailto:olli@pettay.fi Olli Pettay]
|group=dev-platform
|source_dirs=dom/file, dom/filesystem
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM: File
}}

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

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

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

{{Module
|name=Editor
|description=
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

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

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

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

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

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

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

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

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

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

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

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

{{Module
|name=I18N Library
|description=
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]
|group=dev-i18n
|source_dirs=intl/
|url=http://mozilla.org/projects/intl/index.html
|components=Core::Internationalization
}}

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

{{Module
|name=IPC
|description=Native message-passing between threads and processes
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:jld@mozilla.com Jed Davis], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:amccreight@mozilla.com Andrew McCreight]
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:danderson@mozilla.com David Anderson], [mailto:kchen@mozilla.com Kan-Ru Chen], [mailto:btseng@mozilla.com Bevis Tseng]
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

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

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

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

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

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

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

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

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

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

{{Module
|name=Media Playback
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]
|group=dev-media
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/
|url=
|components=Core::Audio/Video
}}

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

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

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

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

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

{{Module
|name=MSCOM
|description=Integration with Microsoft Distributed COM
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]
|group=dev-platform
|source_dirs=ipc/mscom/%
|url=
|components=Core::IPC: MSCOM}}

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

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

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

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

{{Module
|name=Preferences
|description=Preference library
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:felipe@mozilla.com Felipe Gomes], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-platform
|source_dirs=modules/libpref/
|url=
|components=Core::Preferences: Backend
}}

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

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

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

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

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

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:martin.thomson@gmail.com Martin Thomson]
|ownersemeritus=[mailto:ttaubert@mozilla.com Tim Taubert]
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:wtc@google.com Wan-Teh Chang], [mailto:dueno@redhat.com Daiki Ueno]
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM
}}

{{Module
|name=Static analysis & rewriting for C++
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.
|owner=[mailto:nika@thelayzells.com Nika Layzell] (while Ehsan is away)
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:andi@mozilla.com Andi-Bogdan Postelnicu]
|group=dev-platform
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools
|url=
|components=Core::Rewriting & Analysis
}}
{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner= [mailto:cam@mcc.id.au Cameron McCormack]
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/style/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=Tamarin
|description=VM for ActionScript and JavaScript
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]
|group=dev-tech-js-engine
|source_dirs=js/tamarin
|url=http://www.mozilla.org/projects/tamarin/
http://wiki.mozilla.org/tamarin/
http://hg.mozilla.org/tamarin-central/
http://hg.mozilla.org/tamarin-tracing/
|components=Tamarin
}}

{{Module
|name=Test Harness
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill, Marionette, Firefox UI Tests. Requests for new harnesses should go to Testing::General.
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), Rob Campbell (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (Marionette, Firefox UI tests), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette), [mailto:dminor@mozilla.com Dan Minor], [mailto:mjzffr@gmail.com Maja Frydrychowicz] (Marionette, Firefox UI tests),

|group=dev-quality
|source_dirs=/testing
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js
}}

{{Module
|name=Testing Infrastructure
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker
|owner=[mailto:jmaher@mozilla.com Joel Maher]
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], Rob Campbell, [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]
|group=dev-quality
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::Infrastructure
}}

{{Module
|name=JS Marionette
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye>
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk>
|source_dirs=gaia/tests/jsmarionette
|components=Testing::JSMarionette
|group=dev-gaia
}}

{{Module
|name=XPCShell Test Harness
|description=The XPCShell Harness
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]
|peers=[mailto:jmaher@mozilla.com Joel Maher]
|source_dirs=testing/xpcshell
|components=Testing::XPCShell Harness
}}

{{Module
|name=Update Service
|description=server code for Mozilla Update services (aus, addons, pfs)
|owner=Mike Morgan
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]
|group=dev-amo
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/
|url=http://wiki.mozilla.org/wiki/AMO
|components=AUS::Administration, AUS::Systems
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:mstange@themasta.com Markus Stange]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:padenot@mozilla.com Paul Adenot]
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=Web Painting
|description=painting, display lists, and layer construction
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]
|group=dev-tech-layout
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses
|url=http://mozilla.org/newlayout/doc/ ,
http://lxr.mozilla.org/mozilla/source/layout/doc/
|components=Core::Layout: Web Painting
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC, Core::WebRTC Networking
}}

{{Module
|name=WebVR
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration
|owner=[mailto:kgilbert@mozilla.com Kip Gilbert]
|peers=[mailto:dmu@mozilla.com Daosheng Mu]
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=dom/vr, gfx/vr
|url=https://mozvr.com/
|components=Core::WebVR
}}

{{Module
|name=Widget
|description=
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter],
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup
}}

{{Module
|name=Widget - Android
|description=The Android Port
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]
|peers=[mailto:jwillcox@mozilla.com James Willcox]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=supported X widgetry and gfx
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - OS X
|description= Gecko's OS X compatibility layer.
|owner=[mailto:mstange@themasta.com Markus Stange]
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widgets and desktop integration
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:jmathies@mozilla.com Jim Mathies]
|peersemeritus=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XBL
|description=eXtensible Binding Language
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xbl
|source_dirs=dom/xbl/
|url=http://www.mozilla.org/projects/xbl/
|components=Core::XBL
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|peers=[mailto:erahm@mozilla.com Eric Rahm]
|ownersemeritus=Benjamin Smedberg
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:me@kylehuey.com Kyle Huey]
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XPInstall
|description=
|owner=[mailto:dveditz@mozilla.com Dan Veditz]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|group=dev-tech-xpinstall
|source_dirs=xpinstall/
|url=
|components=Core::Installer: XPInstall Engine
}}

{{Module
|name=XPToolkit
|description=Cross-platform user interface toolkit
|owner=
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]
|group=dev-tech-xul
|source_dirs=dom/xul/, layout/xul/
|url=http://www.mozilla.org/xpfe/
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]
|peers=
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux
|description=Sandboxing for the Linux platform
|owner=[mailto:jld@mozilla.com Jed Davis]
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]
|peers=Same as Build Config
|group=dev-builds
|components=Core::Build Config
}}

{{Module
|name=Build Config - Taskgraph
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.
|owner=[mailto:dustin@mozilla.com Dustin Mitchell]
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:mozilla@hocat.ca Tom Prince]
|components=Firefox Build System::Task Configuration
}}

{{Module
|name=WebRTC Media
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson],
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Audio/Video)
}}

{{Module
|name=WebRTC Signaling
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling
|owner=[mailto:bcampen@mozilla.com Byron Campen]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]
|group=dev-media
|source_dirs=/media/webrtc/signaling/
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Signaling)
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::Find Backend
Core::General
Core::HTML: Form Submission
Core::History: Global
Core::Image Blocking
Core::Localization
Core::Networking: Domain Lists
Core::Selection
Core::Serializers
Core::Spelling checker
Core::X-remote
Core::XUL
</pre>
</noinclude>

JavaScript:New to SpiderMonkey

2018-03-07T17:21:41Z

Jorend: /* Build the js shell */ deduplicate, point people to the build documentation for all issues

== 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
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
cd ..

If this doesn't work, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation the SpiderMonkey build documentation].

=== 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 a number of different benchmark suites.

* v8
* SunSpider: One of the original js benchmarks. No real value left.
* Octane: Another js benchmark that we heavily optimized for in the past. Isn't representative of current web workloads.
* speedometer: A full browser benchmark. Testing react, ember, etc. Intended to be a better measure of "responsiveness". We are currently optimizing for version 2 it.

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 used to be the way most people managed their SpiderMonkey workflow (though these days many people use native hg, native hg + evolution, or git):

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. An irc bot can automate this process for a single file if you enter "/msg mrgiggles who can review something.cpp?" into your irc client.

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 will 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 will need to hang around to make sure you didn't break something. It is difficult to determine what failures are real and what are what we call "intermittent oranges" ("orange" because that is the color used on our continuous integration dashboard for test failures). If you do break something, a sheriff will probably let you know via IRC and will probably back your patch out. You can always ask [irc://irc.mozilla.org/#jsapi for help] determining what is going on. (Over time you'll get a feel for figuring out when breakage is real on your own.)

== 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 ===

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

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h and the files in http://hg.mozilla.org/mozilla-central/file/tip/js/public

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
Or watch one of the JS components in the Core product: JavaScript Engine, JavaScript Engine: JIT, JavaScript: GC, or JavaScript: Standard Library

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:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

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 exceptions, and generally avoid virtual functions for core data, 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/integration/mozilla-inbound mozilla-inbound repository]. A link to the commit is then automatically added as a comment to the bug. mozilla-inbound is periodically merged to mozilla-central by a Sheriff. This exempts us from watching [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound treeherder] to check for failures caused by our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

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

[https://blog.mozilla.org/sfink/2017/06/01/sfink-mozilla-workflow/ Steve Fink: Mozilla workflow]

I (Paul Bone) suggest stating with a [http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/unifiedrepo.html unified repository] checkout with the extensions and customization from Steve's workflow, using [https://www.mercurial-scm.org/wiki/ShareExtension hg share] to create workspaces, use bookmarks to track your new feature developments, and using [https://www.mercurial-scm.org/wiki/HisteditExtension hg histedit] and [https://www.mercurial-scm.org/wiki/RebaseExtension hg rebase] to prepare your patches for publication.

=== 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 [https://treeherder.mozilla.org/#/jobs?repo=try TreeHerder]. 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]]

JavaScript:New to SpiderMonkey

2018-03-07T17:20:03Z

Jorend: /* Build the js shell */ back out comment about python which dupilcates the build documentation

== 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
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
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].

<tt>VPATH</tt> builds, also called out-of-source builds, must be used, hence the <tt>mkdir</tt> above is not an options.

It is not sufficient to have ''autoconf'' installed on your system, that happens to have the version 2.13. For the <tt>../configure</tt> process a binary called <tt>autoconf2.13</tt> or <tt>autoconf-2.13</tt> must be on your <tt>$PATH</tt>.

=== 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 a number of different benchmark suites.

* v8
* SunSpider: One of the original js benchmarks. No real value left.
* Octane: Another js benchmark that we heavily optimized for in the past. Isn't representative of current web workloads.
* speedometer: A full browser benchmark. Testing react, ember, etc. Intended to be a better measure of "responsiveness". We are currently optimizing for version 2 it.

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 used to be the way most people managed their SpiderMonkey workflow (though these days many people use native hg, native hg + evolution, or git):

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. An irc bot can automate this process for a single file if you enter "/msg mrgiggles who can review something.cpp?" into your irc client.

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 will 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 will need to hang around to make sure you didn't break something. It is difficult to determine what failures are real and what are what we call "intermittent oranges" ("orange" because that is the color used on our continuous integration dashboard for test failures). If you do break something, a sheriff will probably let you know via IRC and will probably back your patch out. You can always ask [irc://irc.mozilla.org/#jsapi for help] determining what is going on. (Over time you'll get a feel for figuring out when breakage is real on your own.)

== 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 ===

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

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h and the files in http://hg.mozilla.org/mozilla-central/file/tip/js/public

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
Or watch one of the JS components in the Core product: JavaScript Engine, JavaScript Engine: JIT, JavaScript: GC, or JavaScript: Standard Library

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:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

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 exceptions, and generally avoid virtual functions for core data, 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/integration/mozilla-inbound mozilla-inbound repository]. A link to the commit is then automatically added as a comment to the bug. mozilla-inbound is periodically merged to mozilla-central by a Sheriff. This exempts us from watching [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound treeherder] to check for failures caused by our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

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

[https://blog.mozilla.org/sfink/2017/06/01/sfink-mozilla-workflow/ Steve Fink: Mozilla workflow]

I (Paul Bone) suggest stating with a [http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/unifiedrepo.html unified repository] checkout with the extensions and customization from Steve's workflow, using [https://www.mercurial-scm.org/wiki/ShareExtension hg share] to create workspaces, use bookmarks to track your new feature developments, and using [https://www.mercurial-scm.org/wiki/HisteditExtension hg histedit] and [https://www.mercurial-scm.org/wiki/RebaseExtension hg rebase] to prepare your patches for publication.

=== 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 [https://treeherder.mozilla.org/#/jobs?repo=try TreeHerder]. 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]]

JavaScript:SpiderMonkey:Directories

2018-01-12T18:04:56Z

Jorend: fmt

This page describes how we want to organize the SpiderMonkey source code, in subdirectories under js/src.

The reason we have this document is that currently it's not organized this way. It's a bit of a mess just now.

=== Directories under js/src ===

The directories under js/src should be like this:

* gc - Heap allocation and garbage collection.

* vm - JS value representation and code execution. Files that definitely belong there:

Stack.*, Script.*, Interpreter.*, Opcodes.h, PIC.*
String.*, Symbol.*, Atom.*, Value.cpp, Id.cpp
Shape.*, Object.*, ShapedObject.*, NativeObject.*, Shape.*, ObjectGroup.*, TypeInference.*
Context.*, Runtime.*, Realm.*, GlobalObject.*

The vm directory will also hold a bunch of stuff that is not so "core" but still mainly vm-related, like UbiNode.cpp, SelfHosting.*, TemplateRegistry.h, Xdr.*, maybe StructuredClone.*

* builtin - JS-facing stuff. Lots of JSNatives and Classes; self-hosted code. Ideally, each file in here is fairly peripheral to the core business of the JS engine, but it will remain common for the JITs to need to see JSNative function pointers, and for builtins to need access to non-public GC primitives, etc. etc.

* jit - The JITs.

* frontend - Compiling JS code to bytecode.

* ds - Data structures.

* shell - The repl.

* editline, perf, vtune - It's OK that we have extra directories for these bits and pieces.

* irregexp - Vendored libraries are OK too.

* util - New junk-drawer directory, read on for rationale.

=== Focusing the vm directory on VM stuff ===

There's a lot of great stuff in js/src/vm, like JSONPrinter.h and Time.h, that is VM-related in no way whatsoever. It seems we have already decided to have a util directory; maybe then we should call it js/src/util and reserve js/src/vm for the actual VM.

We should move most of the Object subclasses out of vm. There's a spectrum of how silly it is to have them in there:

Very Silly Indeed
* DateObject -> builtin/, times a million
* RegExpObject -> builtin/

On Consideration, Pretty Silly
* BooleanObject, NumberObject, StringObject -> builtin/
* ErrorObject -> builtin/

Not Quite So Silly
* ArrayObject, TypedArrayObject, SharedArrayObject: We would love to move this to builtin/ eventually. I'm not sure we're ready. Certainly there is no clear abstraction boundary.
* Function, AsyncFunction: The same. (I moved Function in here myself in this patch stack...)

Barely Silly
* ArgumentsObject and GlobalObject: Very tied to the interpreter; we can leave them in vm.
* EnvironmentObject: Even more so.

Everything with JSPropertySpecs would ideally live in js/src/builtin.

JavaScript:SpiderMonkey:Coding Style

2018-01-12T16:16:57Z

Jorend: link to directories

= Code Organization =

See [[JavaScript:SpiderMonkey:Directories]].

= Functions =

* Public function names begin with JS_ followed by capitalized "intercaps", e.g. JS_NewObject.
* Extern but library-private function names use a js_ prefix and mixed case, e.g. js_SearchScope.
* Most static function names have unprefixed, mixed-case names: GetChar.
* But static native methods of JS objects have lowercase, underscore-separated or intercaps names, e.g., str_indexOf.
* Function return types are on a separate line preceding the function name.
* Function braces go on the line following the function name.
void DoThis() /* bad */
{
...
}
void
DoThis() /* OK */
{
...
}

= Other Symbols =

* Library-private and static data use underscores, not intercaps (but library-private data do use a js_ prefix).
* Scalar type names are lowercase and js-prefixed: jsdouble.
* Aggregate type names are JS-prefixed and mixed-case: JSObject.
* Macros are generally ALL_CAPS and underscored, to call out potential side effects, multiple uses of a formal argument, etc. Line continuation characters should all line up, in column 79 if that exceeds the width of all the macro text. Macro parameters should be of the form name_ (instead of something like __name).

= Indentation =

* Use spaces, not tabs. There should be no tabs in source files.
* Four spaces of indentation per statement nesting level.
* "<code>case L:</code>" labels in <code>switch</code> statements count as half of a nesting level, so indent two spaces, with the labeled statements indenting two more for a standard four spaces indentation from <code>switch</code> to a case-controlled statement.
switch (discriminant) {
case L1:
DoSomething();
. . .
}
* Function arguments that overflow the first line of the call expression should be aligned to underhang the first argument (to start in overflow lines in the column after the opening parenthesis).
JS_SetContext(rt, /* bad */
cx);
JS_SetContext(rt, /* OK */
cx);

= Whitespace in declarations =

These rules are inconsistently applied. Be consistent with the code you're editing rather than adhere too closely to these guidelines!

* In a declaration of a pointer, the <code>*</code> goes with the type:
char *s; /* bad */
char* s; /* OK */
* In C++ method declarations with default arguments, use spaces and comments like so:
static void
Frob(JSContext* cx, uint32_t defaultValue = 0);
static void
Frob(JSContext* cx, uint32_t defaultValue /* = 0 */)
{
/* ... */
}

= Other whitespace =

* Code should fit within 99 columns; comments should fit within 80 columns; both figures include indentation. Break down lines that are too long by splitting after a binary operator.
* Exception: in a <code>switch</code> statement where each case is a trivially-short statement, it's ok to put the <code>case</code>, the statement, and the <code>break;</code> all on one line.
* Comment <code>/* FALL THROUGH */</code> in place of missing <code>break</code> when intentionally falling through from one case-controlled statement sequence into another, or into the <code>default</code> statements.
* Do not use spaces between a function name and its arguments list, or between an array name and the square bracket. Also, do no use spaces after a bracket. Use a space after a comma to separate arguments.
JS_SetContext ( rt, cx ); /* bad */
JS_SetContext(rt, cx); /* OK */
* Use a space between a C keyword and parentheses.
if(condition) /* bad */
if (condition) /* OK */
* In a conditional, if the condition and consequent (and, if present, any number of <code>else if</code>/<code>else</code> alternatives and associated conditions) occupy single lines, no braces are used.
if (today == "Tuesday")
puts("I don't have my wallet on me.");
else
puts("I would gladly pay you on Tuesday for a hamburger today.");
However, if ''any'' condition occupies multiple lines, or if a consequent or alternative occupies multiple lines (regardless whether it's a single statement or multiple statements), every consequent and alternative is braced.
if (canSwingFromWeb) {
p->swingFromWeb();
} else {
MOZ_ASSERT(p->isSpiderPig());
p->doWhateverSpiderPigDoes();
}
if (apingOtherMonkey) {
MOZ_ASSERT(monkey->wantsAttention(),
"why else would he be aping another monkey?");
}
if (hungryForBananas && // and a comment makes the line long enough for a linebreak
wantsAttentionInTheWorstWay)
{
p->eatBananasAndPreen();
}
* Conditions with multi-line tests should put the brace on the new line to provide a visual separation between the condition and the body.

types::TypeSet* types = frame.extra(lhs).types;
if (JSOp(*PC) == JSOP_SETPROP && id == types::MakeTypeId(cx, id) &&
types && !types->unknownObject() &&
types->getObjectCount() == 1 &&
types->getTypeObject(0) != NULL &&
!types->getTypeObject(0)->unknownProperties())
{
JS_ASSERT(usePropCache);
types::TypeObject* object = types->getTypeObject(0);
types::TypeSet* propertyTypes = object->getProperty(cx, id, false);
...
} else {
...
}
However, if there is already a visual separation between the condition and the body, putting the { on a new line isn't necessary:

if (forHead->pn_kid1 && NewSrcNote2(cx, cg, SRC_DECL,
(forHead->pn_kid1->isOp(JSOP_DEFVAR))
? SRC_DECL_VAR
: SRC_DECL_LET) < 0) {
return false;
}
* <code>for</code> loop heads go on one line where possible; when not possible, initializer part, update, and termination parts each go on separate lines
for (int i = 0;
i < 5;
i++) { /* bad, could all fit on one line */
doStuff();
}
for (int i = 0; i < 5; i++) /* OK */
doStuff();
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS; ind++) { /* bad */
obj->setSlot(ind, DoubleValue(utcTime));
}
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS;
ind++) { /* OK */
obj->setSlot(ind, DoubleValue(utcTime));
}
* In comments, use one space, not two, between sentences and after a colon.

= Control Flow =

* Minimize indentation using return, break, and continue where appropriate. Prefer return (break, continue) statements to cast out abnormal cases, instead of nesting "if/else" statements and indenting the common cases.
void
MyFunction(int n)
{
if (n) { /* bad */
...
}
}
void
MyFunction(int n)
{
if (!n)
return; /* OK */
...
}

* If an "if" statement controls a "then" clause ending in a return statement, do not use "else" after return.
if (condition) { /* bad */
DoThis();
return;
} else {
DoThat();
}

if (condition) { /* OK */
DoThis();
return;
}
DoThat();

* Avoid similar arbitrary patterns and non-sequiturs:
if (condition) { /* bad */
DoThis();
DoThat();
} else {
CleanUp();
return;
}
DoTheOther();
if (!condition) { /* OK */
CleanUp();
return;
}
DoThis();
DoThat();
DoTheOther();

* Avoid using && or || to mix deciding-whether-to-do-something with error-checking.

if (obj->hasProblems() && !obj->rectify()) /* bad */
return false;

if (obj->hasProblems()) { /* OK */
if (!obj->rectify())
return false;
}

= Comments =

* In C files, always use C style comments. C++ comments are ok otherwise.
* Terminate a comment with a period (so try to make comments be complete sentences).
/* This is a good comment. */
// This is also a good comment.
* For C-style multiline comments, align with any indentation, and start every line with an asterisk. Asterisks stack in the same column. Precede the multiline comment with one empty line unless the prior line ends in a left brace. The first line of the comment contains only leading space followed by <code>/*</code>. Multiline comments should also be bracketed.
<pre>
if (condition) {
/*
* This is a lengthy C-style
* multiline comment.
*/
// This is a length
// C++-style comment
DoYourStuff();
}
</pre>

= Entry Points and Callbacks =

* DLL entry points have their return type expanded within a JS_PUBLIC_API() macro call, to get the right Windows secret type qualifiers in the right places for all build variants.
* Callback functions that might be called from a DLL are similarly macroized with JS_STATIC_DLL_CALLBACK (if the function otherwise would be static to hide its name) or JS_DLL_CALLBACK (this macro takes no type argument; it should be used after the return type and before the function name).

= Data Types and Alignments =

* As with all Mozilla code, SpiderMonkey needs to compile and execute correctly on many platforms, including 64-bits systems.
* JS and NSPR have common roots in the dawn of time (Netscape 2), and the <code>JS_THREADSAFE</code> mode of building SpiderMonkey depends on NSPR, so reading the [http://www.mozilla.org/projects/nspr/reference/html/ NSPR documentation] is well worth your while.
* Not all 64-bit systems use the same integer type model: some are "LP64" (long and pointer are 64 bits, int is 32 bits), while others are "LLP64" (only long long and pointer are 64 bits; long and int are 32 bits).
* Use size_t for unsigned number of bytes variables, ptrdiff_t for signed pointer subtraction results. In particular, do not use uintN, which is just shorthand for unsigned int, and so may not be big enough.

= Header files =

== #ifndef wrappers ==

Use this exact form for #ifndef wrappers in header files:

#ifndef <guard>
#define <guard>
...
#endif // <guard>

GCC and clang recognize this idiom and avoid re-reading headers that use it. Don't put any code before the #ifndef or after the #endif, and don't put anything else in the #ifndef, otherwise the optimization will be thwarted and the file will be multiply-included. (Check with the -H option if you want to be sure.)

Include guards should be named by determining the fully-qualified include path,
then substituting _ for '/' and '.' and '-' in it. For example, js/src/vm/Stack-inl.h's guard is vm_Stack_inl_h_, and js/public/Vector.h's guard is js_Vector_h (because its include path is js/Vector.h).

== #include paths ==

All #include statements should use a fully-qualified (within SpiderMonkey) path, even if it's not necessary. For example, this:

#include "vm/Stack.h"

not:

#include "Stack.h"

This keeps things consistent and helps with the ordering.

For headers in js/public/, the prefix is "js/", e.g.:

#include "js/Vector.h"

For headers in mfbt/, the prefix is "mozilla/", e.g.:

#include "mozilla/Assertions.h"

== #include ordering ==

The following order is used for module X:
* If X-inl.h exists, it goes first. (And X-inl.h's first #include should be X.h.) Otherwise, X.h goes first. This rule ensures that X.h and X-inl.h both #include all the headers that they need themselves.
* mozilla/*.h
* <*.h>
* js*.h
* */*.h (this includes the public JSAPI headers in js/public/*.h which should be included using the form js/*.h)
* js*inlines.h
* */*-inl.h.

Keep (case-insensitive) lexicographic order with each section.

The presence of conditionally-compiled #include statements complicates thing. If you have a single #include statement within a #if/#ifdef/#ifndef block, placing the block in the appropriate section is straightforward. If you have multiple #include statements within a block, use your judgment as to where the best place for it is.

Example for X.cpp:

#include "X.h" // put "X-inl.h" instead, if it exists

#include "mozilla/HashFunctions.h"

#include <string.h>

#include "jsbar.h"
#ifdef BAZ
# include "jsbaz.h"
#endif
#include "jscaz.h"

#include "ds/Baz.h"
#include "js/Bar.h"
#include "vm/Bat.h"

#include "jssqueeinlines.h"
#include "jswoot-inl.h"

#include "frontend/Thingamabob-inl.h"
#include "vm/VirtualReality-inl.h"

= C++ =

== Namespaces ==

* Public functions and types should be in the JS:: namespace, in preference to the old JS/JS_ name prefixes.
* Library-private and friend functions should be in the js:: namespace, in preference to the old js_ name prefix.
* Compile-time-evaluated functions (i.e., template meta-functions) should be in 'js::tl::', the "template library" namespace, to avoid collision with their runtime counterparts.
* In SpiderMonkey .cpp files, it is okay to have 'using namespace js;', but it is not okay to do the same with any other namespace, like JS:: or mozilla::. These can introduce ambiguities that come and go depending on which .cpp files the build system decides to unify.
* If you do have names in JS:: that should be readily available throughout SpiderMonkey, you may add a 'using' declaration to js/src/NamespaceImports.h.
* Avoid unnamed namespaces unless they are necessary to give a class's members internal linkage. Although the C++ standard officially deprecates 'static' on functions, 'static' has the following advantages over unnamed namespaces:
** It is difficult to name functions in unnamed namespaces in gdb.
** Static says "this is a translation-unit-local helper function" on the function, without having to look around for an enclosing "namespace {".

== Enums ==

Older code uses SHOUT_REALLY_LOUD for enum values, newer code uses InterCaps. Enums should be preferred to boolean arguments for ease of understanding at the invocation site.

== Classes ==

* For reasonable-sized classes, put all the fields together, at the top, immediately after any necessary typedefs. For unreasonably large classes, do whatever seems best (but let's try to avoid making more of these).
* Align the braces of a class/struct/enum definition like this:
class JSObject
{
...
};
* Member variable names, private or public, should be decorated with a trailing '_'.
class Fail
{
size_t capacity; // common
T* begin_; // better, gravitate toward this
};
Sometimes a canonical argument name may conflict with a member name. In this case, one can disambiguate with "this->", although such explicit qualification should only be added when necessary:
class C
{
public:
size_t count;
bool fresh;
void change(size_t count) {
this->count = count;
this->fresh = false; // verbose and unnecessary
}
};
* Prefer inline functions to macros.
* We build with C++ exceptions disabled, so most of the <code>std</code> namespace is off-limits, including STL containers. The exception is <code><algorithm></code>, which is mostly OK to use. You can use MFBT. We have some STL-like containers that are used basically everywhere (see js::Vector, js::HashMap, etc.)

=== Initializer lists ===

Initializer lists can break in one of two ways. The first may be preferable when constructors take few arguments:

class Ninja : public WeaponWeilder, public Camouflagible,
public Assassinatable, public ShapeShiftable
{
Ninja() : WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

The other permitted style mitigates longer-identifiers-squishing-text-against-the-right-side-of-the-screen-syndrome by using a half-indented colon:

class Ninja
: public WeaponWeilder, public Camouflagible, public Assassinatable,
public ShapeShiftable
{
Ninja()
: WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

=== Inline methods ===

If the method in question fits on one line and is branch free, do a one liner:

class Eater
{
void eat(Eaten &other) { other.setConsumed(); }
};

If it's too long, put the type, declarator including formals (unless they overflow), and left brace all on the first line:

class Eater
{
Food* obtainFoodFromEatery(Eatery &eatery) {
if (!eatery.hasFood())
return NULL;
return eatery.purchaseFood();
}
};

For out-of-line inlines (when the definitions are too unwieldy to place in the class definition) use the inline keyword as an indicator that there's an out-of-line inline definition:

class SpaceGoo
{
inline BlobbyWrapper* enblob(Entity &other);
};

inline BlobbyWrapper*
SpaceGoo::enblob(Entity &other)
{
/* ... */
}

== References ==

* [https://developer.mozilla.org/en/Mozilla_Coding_Style_Guide Mozilla's coding style guide].
* [http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml Google's C++ coding style guide].

= Exceptions to this coding style =

SpiderMonkey contains some code imported from other projects, e.g. ctypes/libffi/, that is minimally modified. Such code does not have to follow SpiderMonkey style.

JavaScript:SpiderMonkey:Directories

2018-01-12T16:15:44Z

Jorend: spelling

This page describes how we want to organize the SpiderMonkey source code, in subdirectories under js/src.

The reason we have this document is that currently it's not organized this way. It's a bit of a mess just now.

=== Directories under js/src ===

The directories under js/src should be like this:

* gc - Heap allocation and garbage collection.

* vm - JS value representation and code execution. Files that definitely belong there:

Stack.*, Script.*, Interpreter.*, Opcodes.h, PIC.*
String.*, Symbol.*, Atom.*, Value.cpp, Id.cpp
Shape.*, Object.*, ShapedObject.*, NativeObject.*, Shape.*, ObjectGroup.*, TypeInference.*
Context.*, Runtime.*, Realm.*, GlobalObject.*

The directory will also hold a bunch of stuff that is not so "core" but still mainly vm-related, like UbiNode.cpp, SelfHosting.*, TemplateRegistry.h, Xdr.*, maybe StructuredClone.*

* builtin - JS-facing stuff. Lots of JSNatives and Classes; self-hosted code. Ideally, each file in here is fairly peripheral to the core business of the JS engine, but it will remain common for the JITs to need to see JSNative function pointers, and for builtins to need access to non-public GC primitives, etc. etc.

* jit - The JITs.

* frontend - Compiling JS code to bytecode.

* ds - Data structures.

* shell - The repl.

* editline, perf, vtune - It's OK that we have extra directories for these bits and pieces.

* irregexp - Vendored libraries are OK too.

* util - New junk-drawer directory, read on for rationale.

=== Focusing the vm directory on VM stuff ===

There's a lot of great stuff in js/src/vm, like JSONPrinter.h and Time.h, that is VM-related in no way whatsoever. It seems we have already decided to have a util directory; maybe then we should call it js/src/util and reserve js/src/vm for the actual VM.

We should move most of the Object subclasses out of vm. There's a spectrum of how silly it is to have them in there:

Very Silly Indeed
* DateObject -> builtin/, times a million
* RegExpObject -> builtin/

On Consideration, Pretty Silly
* BooleanObject, NumberObject, StringObject -> builtin/
* ErrorObject -> builtin/

Not Quite So Silly
* ArrayObject, TypedArrayObject, SharedArrayObject: We would love to move this to builtin/ eventually. I'm not sure we're ready. Certainly there is no clear abstraction boundary.
* Function, AsyncFunction: The same. (I moved Function in here myself in this patch stack...)

Barely Silly
* ArgumentsObject and GlobalObject: Very tied to the interpreter; we can leave them in vm.
* EnvironmentObject: Even more so.

Everything with JSPropertySpecs would ideally live in js/src/builtin.

JavaScript:SpiderMonkey:Directories

2018-01-12T16:15:03Z

Jorend: fmt

This page describes how we want to organize the SpiderMonkey source code, in subdirectories under js/src.

The reason we have this document is that currently it's not organized this way. It's a bit of a mess just now.

=== Directories under js/src ===

The directories under js/src should be like this:

* gc - Heap allocation and garbage collection.

* vm - JS value representation and code execution. Files that definitely belong there:

Stack.*, Script.*, Interpreter.*, Opcodes.h, PIC.*
String.*, Symbol.*, Atom.*, Value.cpp, Id.cpp
Shape.*, Object.*, ShapedObject.*, NativeObject.*, Shape.*, ObjectGroup.*, TypeInference.*
Context.*, Runtime.*, Realm.*, GlobalObject.*

The directory will also hold a bunch of stuff that is not so "core" but still mainly vm-related, like UbiNode.cpp, SelfHosting.*, TemplateRegistry.h, Xdr.*, maybe StructuredClone.*

* builtin - JS-facing stuff. Lots of JSNatives and Classes; self-hosted code. Ideally, each file in here is fairly peripheral to the core business of the JS engine, but it will remain common for the JITs to need to see JSNative function pointers, and for builtins to need access to non-public GC primitives, etc. etc.

* jit - The JITs.

* frontend - Compiling JS code to bytecode.

* ds - Data structures.

* shell - The repl.

* editline, perf, vtune - It's OK that we have extra directories for these bits and pieces.

* irregexp - Vendored libraries are OK too.

* util - New junk-drawer directory, read on for rationale.

=== Focusing the vm directory on VM stuff ===

There's a lot of great stuff in js/src/vm, like JSONPrinter.h and Time.h, that is VM-related in no way whatsoever. It seems we have already decided to have a util directory; maybe then we should call it js/src/util and reserve js/src/vm for the actual VM.

We should move most of the Object subclasses out of vm. There's a spectrum of how silly it is to have them in there:

Very Silly Indeed
* DateObject -> builtin/, times a million
* RegExpObject -> builtin/

On Consideration, Pretty Silly
* BooleanObject, NumberObject, StringObject -> builtin/
* ErrorObject -> builtin/

Not Quite So Silly
* ArrayObject, TypedArrayObject, SharedArrayObject: We would love to move this to builtin/ eventually. I'm not sure we're ready. Certainly there is no clear abstraction boundary.
* Function, AsyncFunction: The same. (I moved Function in here myself in this patch stack...)

Barely Silly
* ArgumentsObject and Global object: Very tied to the interpreter; we can leave them in vm.
* EnvironmentObject: Even more so.

Everything with JSPropertySpecs would ideally live in js/src/builtin.

JavaScript:SpiderMonkey:Directories

2018-01-12T16:14:07Z

Jorend: Created page with "This page describes how we want to organize the SpiderMonkey source code, in subdirectories under js/src. The reason we have this document is that currently it's not organize..."

This page describes how we want to organize the SpiderMonkey source code, in subdirectories under js/src.

The reason we have this document is that currently it's not organized this way. It's a bit of a mess just now.

## Long-term goal

The directories under js/src should be like this:

* gc - Heap allocation and garbage collection.

* vm - JS value representation and code execution. Files that definitely belong there:

Stack.*, Script.*, Interpreter.*, Opcodes.h, PIC.*
String.*, Symbol.*, Atom.*, Value.cpp, Id.cpp
Shape.*, Object.*, ShapedObject.*, NativeObject.*, Shape.*, ObjectGroup.*, TypeInference.*
Context.*, Runtime.*, Realm.*, GlobalObject.*

The directory will also hold a bunch of stuff that is not so "core" but still mainly vm-related, like UbiNode.cpp, SelfHosting.*, TemplateRegistry.h, Xdr.*, maybe StructuredClone.*

* builtin - JS-facing stuff. Lots of JSNatives and Classes; self-hosted code. Ideally, each file in here is fairly peripheral to the core business of the JS engine, but it will remain common for the JITs to need to see JSNative function pointers, and for builtins to need access to non-public GC primitives, etc. etc.

* jit - The JITs.

* frontend - Compiling JS code to bytecode.

* ds - Data structures.

* shell - The repl.

* editline, perf, vtune - It's OK that we have extra directories for these bits and pieces.

* irregexp - Vendored libraries are OK too.

* util - New junk-drawer directory, read on for rationale.

## Focusing the vm directory on VM stuff

There's a lot of great stuff in js/src/vm, like JSONPrinter.h and Time.h, that is VM-related in no way whatsoever. It seems we have already decided to have a util directory; maybe then we should call it js/src/util and reserve js/src/vm for the actual VM.

We should move most of the Object subclasses out of vm. There's a spectrum of how silly it is to have them in there:

Very Silly Indeed
* DateObject -> builtin/, times a million
* RegExpObject -> builtin/

On Consideration, Pretty Silly
* BooleanObject, NumberObject, StringObject -> builtin/
* ErrorObject -> builtin/

Not Quite So Silly
* ArrayObject, TypedArrayObject, SharedArrayObject: We would love to move this to builtin/ eventually. I'm not sure we're ready. Certainly there is no clear abstraction boundary.
* Function, AsyncFunction: The same. (I moved Function in here myself in this patch stack...)

Barely Silly
* ArgumentsObject and Global object: Very tied to the interpreter; we can leave them in vm.
* EnvironmentObject: Even more so.

Everything with JSPropertySpecs would ideally live in js/src/builtin.

JavaScript:SpiderMonkey:Coding Style

2017-10-02T15:07:54Z

Jorend: /* Classes */ tweaks to code samples, for verisimilitude

= Functions =

* Public function names begin with JS_ followed by capitalized "intercaps", e.g. JS_NewObject.
* Extern but library-private function names use a js_ prefix and mixed case, e.g. js_SearchScope.
* Most static function names have unprefixed, mixed-case names: GetChar.
* But static native methods of JS objects have lowercase, underscore-separated or intercaps names, e.g., str_indexOf.
* Function return types are on a separate line preceding the function name.
* Function braces go on the line following the function name.
void DoThis() /* bad */
{
...
}
void
DoThis() /* OK */
{
...
}

= Other Symbols =

* Library-private and static data use underscores, not intercaps (but library-private data do use a js_ prefix).
* Scalar type names are lowercase and js-prefixed: jsdouble.
* Aggregate type names are JS-prefixed and mixed-case: JSObject.
* Macros are generally ALL_CAPS and underscored, to call out potential side effects, multiple uses of a formal argument, etc. Line continuation characters should all line up, in column 79 if that exceeds the width of all the macro text. Macro parameters should be of the form name_ (instead of something like __name).

= Indentation =

* Use spaces, not tabs. There should be no tabs in source files.
* Four spaces of indentation per statement nesting level.
* "<code>case L:</code>" labels in <code>switch</code> statements count as half of a nesting level, so indent two spaces, with the labeled statements indenting two more for a standard four spaces indentation from <code>switch</code> to a case-controlled statement.
switch (discriminant) {
case L1:
DoSomething();
. . .
}
* Function arguments that overflow the first line of the call expression should be aligned to underhang the first argument (to start in overflow lines in the column after the opening parenthesis).
JS_SetContext(rt, /* bad */
cx);
JS_SetContext(rt, /* OK */
cx);

= Whitespace in declarations =

These rules are inconsistently applied. Be consistent with the code you're editing rather than adhere too closely to these guidelines!

* In a declaration of a pointer, the <code>*</code> goes with the type:
char *s; /* bad */
char* s; /* OK */
* In C++ method declarations with default arguments, use spaces and comments like so:
static void
Frob(JSContext* cx, uint32_t defaultValue = 0);
static void
Frob(JSContext* cx, uint32_t defaultValue /* = 0 */)
{
/* ... */
}

= Other whitespace =

* Code should fit within 99 columns; comments should fit within 80 columns; both figures include indentation. Break down lines that are too long by splitting after a binary operator.
* Exception: in a <code>switch</code> statement where each case is a trivially-short statement, it's ok to put the <code>case</code>, the statement, and the <code>break;</code> all on one line.
* Comment <code>/* FALL THROUGH */</code> in place of missing <code>break</code> when intentionally falling through from one case-controlled statement sequence into another, or into the <code>default</code> statements.
* Do not use spaces between a function name and its arguments list, or between an array name and the square bracket. Also, do no use spaces after a bracket. Use a space after a comma to separate arguments.
JS_SetContext ( rt, cx ); /* bad */
JS_SetContext(rt, cx); /* OK */
* Use a space between a C keyword and parentheses.
if(condition) /* bad */
if (condition) /* OK */
* In a conditional, if the condition and consequent (and, if present, any number of <code>else if</code>/<code>else</code> alternatives and associated conditions) occupy single lines, no braces are used.
if (today == "Tuesday")
puts("I don't have my wallet on me.");
else
puts("I would gladly pay you on Tuesday for a hamburger today.");
However, if ''any'' condition occupies multiple lines, or if a consequent or alternative occupies multiple lines (regardless whether it's a single statement or multiple statements), every consequent and alternative is braced.
if (canSwingFromWeb) {
p->swingFromWeb();
} else {
MOZ_ASSERT(p->isSpiderPig());
p->doWhateverSpiderPigDoes();
}
if (apingOtherMonkey) {
MOZ_ASSERT(monkey->wantsAttention(),
"why else would he be aping another monkey?");
}
if (hungryForBananas && // and a comment makes the line long enough for a linebreak
wantsAttentionInTheWorstWay)
{
p->eatBananasAndPreen();
}
* Conditions with multi-line tests should put the brace on the new line to provide a visual separation between the condition and the body.

types::TypeSet* types = frame.extra(lhs).types;
if (JSOp(*PC) == JSOP_SETPROP && id == types::MakeTypeId(cx, id) &&
types && !types->unknownObject() &&
types->getObjectCount() == 1 &&
types->getTypeObject(0) != NULL &&
!types->getTypeObject(0)->unknownProperties())
{
JS_ASSERT(usePropCache);
types::TypeObject* object = types->getTypeObject(0);
types::TypeSet* propertyTypes = object->getProperty(cx, id, false);
...
} else {
...
}
However, if there is already a visual separation between the condition and the body, putting the { on a new line isn't necessary:

if (forHead->pn_kid1 && NewSrcNote2(cx, cg, SRC_DECL,
(forHead->pn_kid1->isOp(JSOP_DEFVAR))
? SRC_DECL_VAR
: SRC_DECL_LET) < 0) {
return false;
}
* <code>for</code> loop heads go on one line where possible; when not possible, initializer part, update, and termination parts each go on separate lines
for (int i = 0;
i < 5;
i++) { /* bad, could all fit on one line */
doStuff();
}
for (int i = 0; i < 5; i++) /* OK */
doStuff();
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS; ind++) { /* bad */
obj->setSlot(ind, DoubleValue(utcTime));
}
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS;
ind++) { /* OK */
obj->setSlot(ind, DoubleValue(utcTime));
}
* In comments, use one space, not two, between sentences and after a colon.

= Control Flow =

* Minimize indentation using return, break, and continue where appropriate. Prefer return (break, continue) statements to cast out abnormal cases, instead of nesting "if/else" statements and indenting the common cases.
void
MyFunction(int n)
{
if (n) { /* bad */
...
}
}
void
MyFunction(int n)
{
if (!n)
return; /* OK */
...
}

* If an "if" statement controls a "then" clause ending in a return statement, do not use "else" after return.
if (condition) { /* bad */
DoThis();
return;
} else {
DoThat();
}

if (condition) { /* OK */
DoThis();
return;
}
DoThat();

* Avoid similar arbitrary patterns and non-sequiturs:
if (condition) { /* bad */
DoThis();
DoThat();
} else {
CleanUp();
return;
}
DoTheOther();
if (!condition) { /* OK */
CleanUp();
return;
}
DoThis();
DoThat();
DoTheOther();

* Avoid using && or || to mix deciding-whether-to-do-something with error-checking.

if (obj->hasProblems() && !obj->rectify()) /* bad */
return false;

if (obj->hasProblems()) { /* OK */
if (!obj->rectify())
return false;
}

= Comments =

* In C files, always use C style comments. C++ comments are ok otherwise.
* Terminate a comment with a period (so try to make comments be complete sentences).
/* This is a good comment. */
// This is also a good comment.
* For C-style multiline comments, align with any indentation, and start every line with an asterisk. Asterisks stack in the same column. Precede the multiline comment with one empty line unless the prior line ends in a left brace. The first line of the comment contains only leading space followed by <code>/*</code>. Multiline comments should also be bracketed.
<pre>
if (condition) {
/*
* This is a lengthy C-style
* multiline comment.
*/
// This is a length
// C++-style comment
DoYourStuff();
}
</pre>

= Entry Points and Callbacks =

* DLL entry points have their return type expanded within a JS_PUBLIC_API() macro call, to get the right Windows secret type qualifiers in the right places for all build variants.
* Callback functions that might be called from a DLL are similarly macroized with JS_STATIC_DLL_CALLBACK (if the function otherwise would be static to hide its name) or JS_DLL_CALLBACK (this macro takes no type argument; it should be used after the return type and before the function name).

= Data Types and Alignments =

* As with all Mozilla code, SpiderMonkey needs to compile and execute correctly on many platforms, including 64-bits systems.
* JS and NSPR have common roots in the dawn of time (Netscape 2), and the <code>JS_THREADSAFE</code> mode of building SpiderMonkey depends on NSPR, so reading the [http://www.mozilla.org/projects/nspr/reference/html/ NSPR documentation] is well worth your while.
* Not all 64-bit systems use the same integer type model: some are "LP64" (long and pointer are 64 bits, int is 32 bits), while others are "LLP64" (only long long and pointer are 64 bits; long and int are 32 bits).
* Use size_t for unsigned number of bytes variables, ptrdiff_t for signed pointer subtraction results. In particular, do not use uintN, which is just shorthand for unsigned int, and so may not be big enough.

= Header files =

== #ifndef wrappers ==

Use this exact form for #ifndef wrappers in header files:

#ifndef <guard>
#define <guard>
...
#endif // <guard>

GCC and clang recognize this idiom and avoid re-reading headers that use it. Don't put any code before the #ifndef or after the #endif, and don't put anything else in the #ifndef, otherwise the optimization will be thwarted and the file will be multiply-included. (Check with the -H option if you want to be sure.)

Include guards should be named by determining the fully-qualified include path,
then substituting _ for '/' and '.' and '-' in it. For example, js/src/vm/Stack-inl.h's guard is vm_Stack_inl_h_, and js/public/Vector.h's guard is js_Vector_h (because its include path is js/Vector.h).

== #include paths ==

All #include statements should use a fully-qualified (within SpiderMonkey) path, even if it's not necessary. For example, this:

#include "vm/Stack.h"

not:

#include "Stack.h"

This keeps things consistent and helps with the ordering.

For headers in js/public/, the prefix is "js/", e.g.:

#include "js/Vector.h"

For headers in mfbt/, the prefix is "mozilla/", e.g.:

#include "mozilla/Assertions.h"

== #include ordering ==

The following order is used for module X:
* If X-inl.h exists, it goes first. (And X-inl.h's first #include should be X.h.) Otherwise, X.h goes first. This rule ensures that X.h and X-inl.h both #include all the headers that they need themselves.
* mozilla/*.h
* <*.h>
* js*.h
* */*.h (this includes the public JSAPI headers in js/public/*.h which should be included using the form js/*.h)
* js*inlines.h
* */*-inl.h.

Keep (case-insensitive) lexicographic order with each section.

The presence of conditionally-compiled #include statements complicates thing. If you have a single #include statement within a #if/#ifdef/#ifndef block, placing the block in the appropriate section is straightforward. If you have multiple #include statements within a block, use your judgment as to where the best place for it is.

Example for X.cpp:

#include "X.h" // put "X-inl.h" instead, if it exists

#include "mozilla/HashFunctions.h"

#include <string.h>

#include "jsbar.h"
#ifdef BAZ
# include "jsbaz.h"
#endif
#include "jscaz.h"

#include "ds/Baz.h"
#include "js/Bar.h"
#include "vm/Bat.h"

#include "jssqueeinlines.h"
#include "jswoot-inl.h"

#include "frontend/Thingamabob-inl.h"
#include "vm/VirtualReality-inl.h"

= C++ =

== Namespaces ==

* Public functions and types should be in the JS:: namespace, in preference to the old JS/JS_ name prefixes.
* Library-private and friend functions should be in the js:: namespace, in preference to the old js_ name prefix.
* Compile-time-evaluated functions (i.e., template meta-functions) should be in 'js::tl::', the "template library" namespace, to avoid collision with their runtime counterparts.
* In SpiderMonkey .cpp files, it is okay to have 'using namespace js;', but it is not okay to do the same with any other namespace, like JS:: or mozilla::. These can introduce ambiguities that come and go depending on which .cpp files the build system decides to unify.
* If you do have names in JS:: that should be readily available throughout SpiderMonkey, you may add a 'using' declaration to js/src/NamespaceImports.h.
* Avoid unnamed namespaces unless they are necessary to give a class's members internal linkage. Although the C++ standard officially deprecates 'static' on functions, 'static' has the following advantages over unnamed namespaces:
** It is difficult to name functions in unnamed namespaces in gdb.
** Static says "this is a translation-unit-local helper function" on the function, without having to look around for an enclosing "namespace {".

== Enums ==

Older code uses SHOUT_REALLY_LOUD for enum values, newer code uses InterCaps. Enums should be preferred to boolean arguments for ease of understanding at the invocation site.

== Classes ==

* For reasonable-sized classes, put all the fields together, at the top, immediately after any necessary typedefs. For unreasonably large classes, do whatever seems best (but let's try to avoid making more of these).
* Align the braces of a class/struct/enum definition like this:
class JSObject
{
...
};
* Member variable names, private or public, should be decorated with a trailing '_'.
class Fail
{
size_t capacity; // common
T* begin_; // better, gravitate toward this
};
Sometimes a canonical argument name may conflict with a member name. In this case, one can disambiguate with "this->", although such explicit qualification should only be added when necessary:
class C
{
public:
size_t count;
bool fresh;
void change(size_t count) {
this->count = count;
this->fresh = false; // verbose and unnecessary
}
};
* Prefer inline functions to macros.
* We build with C++ exceptions disabled, so most of the <code>std</code> namespace is off-limits, including STL containers. The exception is <code><algorithm></code>, which is mostly OK to use. You can use MFBT. We have some STL-like containers that are used basically everywhere (see js::Vector, js::HashMap, etc.)

=== Initializer lists ===

Initializer lists can break in one of two ways. The first may be preferable when constructors take few arguments:

class Ninja : public WeaponWeilder, public Camouflagible,
public Assassinatable, public ShapeShiftable
{
Ninja() : WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

The other permitted style mitigates longer-identifiers-squishing-text-against-the-right-side-of-the-screen-syndrome by using a half-indented colon:

class Ninja
: public WeaponWeilder, public Camouflagible, public Assassinatable,
public ShapeShiftable
{
Ninja()
: WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

=== Inline methods ===

If the method in question fits on one line and is branch free, do a one liner:

class Eater
{
void eat(Eaten &other) { other.setConsumed(); }
};

If it's too long, put the type, declarator including formals (unless they overflow), and left brace all on the first line:

class Eater
{
Food* obtainFoodFromEatery(Eatery &eatery) {
if (!eatery.hasFood())
return NULL;
return eatery.purchaseFood();
}
};

For out-of-line inlines (when the definitions are too unwieldy to place in the class definition) use the inline keyword as an indicator that there's an out-of-line inline definition:

class SpaceGoo
{
inline BlobbyWrapper* enblob(Entity &other);
};

inline BlobbyWrapper*
SpaceGoo::enblob(Entity &other)
{
/* ... */
}

== References ==

* [https://developer.mozilla.org/en/Mozilla_Coding_Style_Guide Mozilla's coding style guide].
* [http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml Google's C++ coding style guide].

= Exceptions to this coding style =

SpiderMonkey contains some code imported from other projects, e.g. ctypes/libffi/, that is minimally modified. Such code does not have to follow SpiderMonkey style.

JavaScript:SpiderMonkey:Coding Style

2017-10-02T14:50:46Z

Jorend: /* Classes */ add the all-fields-together rule

= Functions =

* Public function names begin with JS_ followed by capitalized "intercaps", e.g. JS_NewObject.
* Extern but library-private function names use a js_ prefix and mixed case, e.g. js_SearchScope.
* Most static function names have unprefixed, mixed-case names: GetChar.
* But static native methods of JS objects have lowercase, underscore-separated or intercaps names, e.g., str_indexOf.
* Function return types are on a separate line preceding the function name.
* Function braces go on the line following the function name.
void DoThis() /* bad */
{
...
}
void
DoThis() /* OK */
{
...
}

= Other Symbols =

* Library-private and static data use underscores, not intercaps (but library-private data do use a js_ prefix).
* Scalar type names are lowercase and js-prefixed: jsdouble.
* Aggregate type names are JS-prefixed and mixed-case: JSObject.
* Macros are generally ALL_CAPS and underscored, to call out potential side effects, multiple uses of a formal argument, etc. Line continuation characters should all line up, in column 79 if that exceeds the width of all the macro text. Macro parameters should be of the form name_ (instead of something like __name).

= Indentation =

* Use spaces, not tabs. There should be no tabs in source files.
* Four spaces of indentation per statement nesting level.
* "<code>case L:</code>" labels in <code>switch</code> statements count as half of a nesting level, so indent two spaces, with the labeled statements indenting two more for a standard four spaces indentation from <code>switch</code> to a case-controlled statement.
switch (discriminant) {
case L1:
DoSomething();
. . .
}
* Function arguments that overflow the first line of the call expression should be aligned to underhang the first argument (to start in overflow lines in the column after the opening parenthesis).
JS_SetContext(rt, /* bad */
cx);
JS_SetContext(rt, /* OK */
cx);

= Whitespace in declarations =

These rules are inconsistently applied. Be consistent with the code you're editing rather than adhere too closely to these guidelines!

* In a declaration of a pointer, the <code>*</code> goes with the type:
char *s; /* bad */
char* s; /* OK */
* In C++ method declarations with default arguments, use spaces and comments like so:
static void
Frob(JSContext* cx, uint32_t defaultValue = 0);
static void
Frob(JSContext* cx, uint32_t defaultValue /* = 0 */)
{
/* ... */
}

= Other whitespace =

* Code should fit within 99 columns; comments should fit within 80 columns; both figures include indentation. Break down lines that are too long by splitting after a binary operator.
* Exception: in a <code>switch</code> statement where each case is a trivially-short statement, it's ok to put the <code>case</code>, the statement, and the <code>break;</code> all on one line.
* Comment <code>/* FALL THROUGH */</code> in place of missing <code>break</code> when intentionally falling through from one case-controlled statement sequence into another, or into the <code>default</code> statements.
* Do not use spaces between a function name and its arguments list, or between an array name and the square bracket. Also, do no use spaces after a bracket. Use a space after a comma to separate arguments.
JS_SetContext ( rt, cx ); /* bad */
JS_SetContext(rt, cx); /* OK */
* Use a space between a C keyword and parentheses.
if(condition) /* bad */
if (condition) /* OK */
* In a conditional, if the condition and consequent (and, if present, any number of <code>else if</code>/<code>else</code> alternatives and associated conditions) occupy single lines, no braces are used.
if (today == "Tuesday")
puts("I don't have my wallet on me.");
else
puts("I would gladly pay you on Tuesday for a hamburger today.");
However, if ''any'' condition occupies multiple lines, or if a consequent or alternative occupies multiple lines (regardless whether it's a single statement or multiple statements), every consequent and alternative is braced.
if (canSwingFromWeb) {
p->swingFromWeb();
} else {
MOZ_ASSERT(p->isSpiderPig());
p->doWhateverSpiderPigDoes();
}
if (apingOtherMonkey) {
MOZ_ASSERT(monkey->wantsAttention(),
"why else would he be aping another monkey?");
}
if (hungryForBananas && // and a comment makes the line long enough for a linebreak
wantsAttentionInTheWorstWay)
{
p->eatBananasAndPreen();
}
* Conditions with multi-line tests should put the brace on the new line to provide a visual separation between the condition and the body.

types::TypeSet* types = frame.extra(lhs).types;
if (JSOp(*PC) == JSOP_SETPROP && id == types::MakeTypeId(cx, id) &&
types && !types->unknownObject() &&
types->getObjectCount() == 1 &&
types->getTypeObject(0) != NULL &&
!types->getTypeObject(0)->unknownProperties())
{
JS_ASSERT(usePropCache);
types::TypeObject* object = types->getTypeObject(0);
types::TypeSet* propertyTypes = object->getProperty(cx, id, false);
...
} else {
...
}
However, if there is already a visual separation between the condition and the body, putting the { on a new line isn't necessary:

if (forHead->pn_kid1 && NewSrcNote2(cx, cg, SRC_DECL,
(forHead->pn_kid1->isOp(JSOP_DEFVAR))
? SRC_DECL_VAR
: SRC_DECL_LET) < 0) {
return false;
}
* <code>for</code> loop heads go on one line where possible; when not possible, initializer part, update, and termination parts each go on separate lines
for (int i = 0;
i < 5;
i++) { /* bad, could all fit on one line */
doStuff();
}
for (int i = 0; i < 5; i++) /* OK */
doStuff();
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS; ind++) { /* bad */
obj->setSlot(ind, DoubleValue(utcTime));
}
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS;
ind++) { /* OK */
obj->setSlot(ind, DoubleValue(utcTime));
}
* In comments, use one space, not two, between sentences and after a colon.

= Control Flow =

* Minimize indentation using return, break, and continue where appropriate. Prefer return (break, continue) statements to cast out abnormal cases, instead of nesting "if/else" statements and indenting the common cases.
void
MyFunction(int n)
{
if (n) { /* bad */
...
}
}
void
MyFunction(int n)
{
if (!n)
return; /* OK */
...
}

* If an "if" statement controls a "then" clause ending in a return statement, do not use "else" after return.
if (condition) { /* bad */
DoThis();
return;
} else {
DoThat();
}

if (condition) { /* OK */
DoThis();
return;
}
DoThat();

* Avoid similar arbitrary patterns and non-sequiturs:
if (condition) { /* bad */
DoThis();
DoThat();
} else {
CleanUp();
return;
}
DoTheOther();
if (!condition) { /* OK */
CleanUp();
return;
}
DoThis();
DoThat();
DoTheOther();

* Avoid using && or || to mix deciding-whether-to-do-something with error-checking.

if (obj->hasProblems() && !obj->rectify()) /* bad */
return false;

if (obj->hasProblems()) { /* OK */
if (!obj->rectify())
return false;
}

= Comments =

* In C files, always use C style comments. C++ comments are ok otherwise.
* Terminate a comment with a period (so try to make comments be complete sentences).
/* This is a good comment. */
// This is also a good comment.
* For C-style multiline comments, align with any indentation, and start every line with an asterisk. Asterisks stack in the same column. Precede the multiline comment with one empty line unless the prior line ends in a left brace. The first line of the comment contains only leading space followed by <code>/*</code>. Multiline comments should also be bracketed.
<pre>
if (condition) {
/*
* This is a lengthy C-style
* multiline comment.
*/
// This is a length
// C++-style comment
DoYourStuff();
}
</pre>

= Entry Points and Callbacks =

* DLL entry points have their return type expanded within a JS_PUBLIC_API() macro call, to get the right Windows secret type qualifiers in the right places for all build variants.
* Callback functions that might be called from a DLL are similarly macroized with JS_STATIC_DLL_CALLBACK (if the function otherwise would be static to hide its name) or JS_DLL_CALLBACK (this macro takes no type argument; it should be used after the return type and before the function name).

= Data Types and Alignments =

* As with all Mozilla code, SpiderMonkey needs to compile and execute correctly on many platforms, including 64-bits systems.
* JS and NSPR have common roots in the dawn of time (Netscape 2), and the <code>JS_THREADSAFE</code> mode of building SpiderMonkey depends on NSPR, so reading the [http://www.mozilla.org/projects/nspr/reference/html/ NSPR documentation] is well worth your while.
* Not all 64-bit systems use the same integer type model: some are "LP64" (long and pointer are 64 bits, int is 32 bits), while others are "LLP64" (only long long and pointer are 64 bits; long and int are 32 bits).
* Use size_t for unsigned number of bytes variables, ptrdiff_t for signed pointer subtraction results. In particular, do not use uintN, which is just shorthand for unsigned int, and so may not be big enough.

= Header files =

== #ifndef wrappers ==

Use this exact form for #ifndef wrappers in header files:

#ifndef <guard>
#define <guard>
...
#endif // <guard>

GCC and clang recognize this idiom and avoid re-reading headers that use it. Don't put any code before the #ifndef or after the #endif, and don't put anything else in the #ifndef, otherwise the optimization will be thwarted and the file will be multiply-included. (Check with the -H option if you want to be sure.)

Include guards should be named by determining the fully-qualified include path,
then substituting _ for '/' and '.' and '-' in it. For example, js/src/vm/Stack-inl.h's guard is vm_Stack_inl_h_, and js/public/Vector.h's guard is js_Vector_h (because its include path is js/Vector.h).

== #include paths ==

All #include statements should use a fully-qualified (within SpiderMonkey) path, even if it's not necessary. For example, this:

#include "vm/Stack.h"

not:

#include "Stack.h"

This keeps things consistent and helps with the ordering.

For headers in js/public/, the prefix is "js/", e.g.:

#include "js/Vector.h"

For headers in mfbt/, the prefix is "mozilla/", e.g.:

#include "mozilla/Assertions.h"

== #include ordering ==

The following order is used for module X:
* If X-inl.h exists, it goes first. (And X-inl.h's first #include should be X.h.) Otherwise, X.h goes first. This rule ensures that X.h and X-inl.h both #include all the headers that they need themselves.
* mozilla/*.h
* <*.h>
* js*.h
* */*.h (this includes the public JSAPI headers in js/public/*.h which should be included using the form js/*.h)
* js*inlines.h
* */*-inl.h.

Keep (case-insensitive) lexicographic order with each section.

The presence of conditionally-compiled #include statements complicates thing. If you have a single #include statement within a #if/#ifdef/#ifndef block, placing the block in the appropriate section is straightforward. If you have multiple #include statements within a block, use your judgment as to where the best place for it is.

Example for X.cpp:

#include "X.h" // put "X-inl.h" instead, if it exists

#include "mozilla/HashFunctions.h"

#include <string.h>

#include "jsbar.h"
#ifdef BAZ
# include "jsbaz.h"
#endif
#include "jscaz.h"

#include "ds/Baz.h"
#include "js/Bar.h"
#include "vm/Bat.h"

#include "jssqueeinlines.h"
#include "jswoot-inl.h"

#include "frontend/Thingamabob-inl.h"
#include "vm/VirtualReality-inl.h"

= C++ =

== Namespaces ==

* Public functions and types should be in the JS:: namespace, in preference to the old JS/JS_ name prefixes.
* Library-private and friend functions should be in the js:: namespace, in preference to the old js_ name prefix.
* Compile-time-evaluated functions (i.e., template meta-functions) should be in 'js::tl::', the "template library" namespace, to avoid collision with their runtime counterparts.
* In SpiderMonkey .cpp files, it is okay to have 'using namespace js;', but it is not okay to do the same with any other namespace, like JS:: or mozilla::. These can introduce ambiguities that come and go depending on which .cpp files the build system decides to unify.
* If you do have names in JS:: that should be readily available throughout SpiderMonkey, you may add a 'using' declaration to js/src/NamespaceImports.h.
* Avoid unnamed namespaces unless they are necessary to give a class's members internal linkage. Although the C++ standard officially deprecates 'static' on functions, 'static' has the following advantages over unnamed namespaces:
** It is difficult to name functions in unnamed namespaces in gdb.
** Static says "this is a translation-unit-local helper function" on the function, without having to look around for an enclosing "namespace {".

== Enums ==

Older code uses SHOUT_REALLY_LOUD for enum values, newer code uses InterCaps. Enums should be preferred to boolean arguments for ease of understanding at the invocation site.

== Classes ==

* For reasonable-sized classes, put all the fields together, at the top, immediately after any necessary typedefs. For unreasonably large classes, do whatever seems best (but let's try to avoid making more of these).
* Align the braces of a class/struct/enum definition like this:
class JSObject
{
...
}
* Member variable names, private or public, should be decorated with a trailing '_'.
class Fail
{
size_t capacity; // common
T* begin_; // better, gravitate toward this
}
Sometimes a canonical argument name may conflict with a member name. In this case, one can disambiguate with "this->", although such explicit qualification should only be added when necessary:
class C
{
size_t count;
bool fresh;
void change(size_t count) {
this->count = count;
this->fresh = false; // verbose and unnecessary
}
};
* Prefer inline functions to macros.
* We build with C++ exceptions disabled, so most of the <code>std</code> namespace is off-limits, including STL containers. The exception is <code><algorithm></code>, which is mostly OK to use. You can use MFBT. We have some STL-like containers that are used basically everywhere (see js::Vector, js::HashMap, etc.)

=== Initializer lists ===

Initializer lists can break in one of two ways. The first may be preferable when constructors take few arguments:

class Ninja : public WeaponWeilder, public Camouflagible,
public Assassinatable, public ShapeShiftable
{
Ninja() : WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

The other permitted style mitigates longer-identifiers-squishing-text-against-the-right-side-of-the-screen-syndrome by using a half-indented colon:

class Ninja
: public WeaponWeilder, public Camouflagible, public Assassinatable,
public ShapeShiftable
{
Ninja()
: WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

=== Inline methods ===

If the method in question fits on one line and is branch free, do a one liner:

class Eater
{
void eat(Eaten &other) { other.setConsumed(); }
};

If it's too long, put the type, declarator including formals (unless they overflow), and left brace all on the first line:

class Eater
{
Food* obtainFoodFromEatery(Eatery &eatery) {
if (!eatery.hasFood())
return NULL;
return eatery.purchaseFood();
}
};

For out-of-line inlines (when the definitions are too unwieldy to place in the class definition) use the inline keyword as an indicator that there's an out-of-line inline definition:

class SpaceGoo
{
inline BlobbyWrapper* enblob(Entity &other);
};

inline BlobbyWrapper*
SpaceGoo::enblob(Entity &other)
{
/* ... */
}

== References ==

* [https://developer.mozilla.org/en/Mozilla_Coding_Style_Guide Mozilla's coding style guide].
* [http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml Google's C++ coding style guide].

= Exceptions to this coding style =

SpiderMonkey contains some code imported from other projects, e.g. ctypes/libffi/, that is minimally modified. Such code does not have to follow SpiderMonkey style.

JavaScript:SpiderMonkey:Coding Style

2017-10-02T14:49:08Z

Jorend: /* Classical OOP */ - reword for 8 years' progress

= Functions =

* Public function names begin with JS_ followed by capitalized "intercaps", e.g. JS_NewObject.
* Extern but library-private function names use a js_ prefix and mixed case, e.g. js_SearchScope.
* Most static function names have unprefixed, mixed-case names: GetChar.
* But static native methods of JS objects have lowercase, underscore-separated or intercaps names, e.g., str_indexOf.
* Function return types are on a separate line preceding the function name.
* Function braces go on the line following the function name.
void DoThis() /* bad */
{
...
}
void
DoThis() /* OK */
{
...
}

= Other Symbols =

* Library-private and static data use underscores, not intercaps (but library-private data do use a js_ prefix).
* Scalar type names are lowercase and js-prefixed: jsdouble.
* Aggregate type names are JS-prefixed and mixed-case: JSObject.
* Macros are generally ALL_CAPS and underscored, to call out potential side effects, multiple uses of a formal argument, etc. Line continuation characters should all line up, in column 79 if that exceeds the width of all the macro text. Macro parameters should be of the form name_ (instead of something like __name).

= Indentation =

* Use spaces, not tabs. There should be no tabs in source files.
* Four spaces of indentation per statement nesting level.
* "<code>case L:</code>" labels in <code>switch</code> statements count as half of a nesting level, so indent two spaces, with the labeled statements indenting two more for a standard four spaces indentation from <code>switch</code> to a case-controlled statement.
switch (discriminant) {
case L1:
DoSomething();
. . .
}
* Function arguments that overflow the first line of the call expression should be aligned to underhang the first argument (to start in overflow lines in the column after the opening parenthesis).
JS_SetContext(rt, /* bad */
cx);
JS_SetContext(rt, /* OK */
cx);

= Whitespace in declarations =

These rules are inconsistently applied. Be consistent with the code you're editing rather than adhere too closely to these guidelines!

* In a declaration of a pointer, the <code>*</code> goes with the type:
char *s; /* bad */
char* s; /* OK */
* In C++ method declarations with default arguments, use spaces and comments like so:
static void
Frob(JSContext* cx, uint32_t defaultValue = 0);
static void
Frob(JSContext* cx, uint32_t defaultValue /* = 0 */)
{
/* ... */
}

= Other whitespace =

* Code should fit within 99 columns; comments should fit within 80 columns; both figures include indentation. Break down lines that are too long by splitting after a binary operator.
* Exception: in a <code>switch</code> statement where each case is a trivially-short statement, it's ok to put the <code>case</code>, the statement, and the <code>break;</code> all on one line.
* Comment <code>/* FALL THROUGH */</code> in place of missing <code>break</code> when intentionally falling through from one case-controlled statement sequence into another, or into the <code>default</code> statements.
* Do not use spaces between a function name and its arguments list, or between an array name and the square bracket. Also, do no use spaces after a bracket. Use a space after a comma to separate arguments.
JS_SetContext ( rt, cx ); /* bad */
JS_SetContext(rt, cx); /* OK */
* Use a space between a C keyword and parentheses.
if(condition) /* bad */
if (condition) /* OK */
* In a conditional, if the condition and consequent (and, if present, any number of <code>else if</code>/<code>else</code> alternatives and associated conditions) occupy single lines, no braces are used.
if (today == "Tuesday")
puts("I don't have my wallet on me.");
else
puts("I would gladly pay you on Tuesday for a hamburger today.");
However, if ''any'' condition occupies multiple lines, or if a consequent or alternative occupies multiple lines (regardless whether it's a single statement or multiple statements), every consequent and alternative is braced.
if (canSwingFromWeb) {
p->swingFromWeb();
} else {
MOZ_ASSERT(p->isSpiderPig());
p->doWhateverSpiderPigDoes();
}
if (apingOtherMonkey) {
MOZ_ASSERT(monkey->wantsAttention(),
"why else would he be aping another monkey?");
}
if (hungryForBananas && // and a comment makes the line long enough for a linebreak
wantsAttentionInTheWorstWay)
{
p->eatBananasAndPreen();
}
* Conditions with multi-line tests should put the brace on the new line to provide a visual separation between the condition and the body.

types::TypeSet* types = frame.extra(lhs).types;
if (JSOp(*PC) == JSOP_SETPROP && id == types::MakeTypeId(cx, id) &&
types && !types->unknownObject() &&
types->getObjectCount() == 1 &&
types->getTypeObject(0) != NULL &&
!types->getTypeObject(0)->unknownProperties())
{
JS_ASSERT(usePropCache);
types::TypeObject* object = types->getTypeObject(0);
types::TypeSet* propertyTypes = object->getProperty(cx, id, false);
...
} else {
...
}
However, if there is already a visual separation between the condition and the body, putting the { on a new line isn't necessary:

if (forHead->pn_kid1 && NewSrcNote2(cx, cg, SRC_DECL,
(forHead->pn_kid1->isOp(JSOP_DEFVAR))
? SRC_DECL_VAR
: SRC_DECL_LET) < 0) {
return false;
}
* <code>for</code> loop heads go on one line where possible; when not possible, initializer part, update, and termination parts each go on separate lines
for (int i = 0;
i < 5;
i++) { /* bad, could all fit on one line */
doStuff();
}
for (int i = 0; i < 5; i++) /* OK */
doStuff();
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS; ind++) { /* bad */
obj->setSlot(ind, DoubleValue(utcTime));
}
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS;
ind++) { /* OK */
obj->setSlot(ind, DoubleValue(utcTime));
}
* In comments, use one space, not two, between sentences and after a colon.

= Control Flow =

* Minimize indentation using return, break, and continue where appropriate. Prefer return (break, continue) statements to cast out abnormal cases, instead of nesting "if/else" statements and indenting the common cases.
void
MyFunction(int n)
{
if (n) { /* bad */
...
}
}
void
MyFunction(int n)
{
if (!n)
return; /* OK */
...
}

* If an "if" statement controls a "then" clause ending in a return statement, do not use "else" after return.
if (condition) { /* bad */
DoThis();
return;
} else {
DoThat();
}

if (condition) { /* OK */
DoThis();
return;
}
DoThat();

* Avoid similar arbitrary patterns and non-sequiturs:
if (condition) { /* bad */
DoThis();
DoThat();
} else {
CleanUp();
return;
}
DoTheOther();
if (!condition) { /* OK */
CleanUp();
return;
}
DoThis();
DoThat();
DoTheOther();

* Avoid using && or || to mix deciding-whether-to-do-something with error-checking.

if (obj->hasProblems() && !obj->rectify()) /* bad */
return false;

if (obj->hasProblems()) { /* OK */
if (!obj->rectify())
return false;
}

= Comments =

* In C files, always use C style comments. C++ comments are ok otherwise.
* Terminate a comment with a period (so try to make comments be complete sentences).
/* This is a good comment. */
// This is also a good comment.
* For C-style multiline comments, align with any indentation, and start every line with an asterisk. Asterisks stack in the same column. Precede the multiline comment with one empty line unless the prior line ends in a left brace. The first line of the comment contains only leading space followed by <code>/*</code>. Multiline comments should also be bracketed.
<pre>
if (condition) {
/*
* This is a lengthy C-style
* multiline comment.
*/
// This is a length
// C++-style comment
DoYourStuff();
}
</pre>

= Entry Points and Callbacks =

* DLL entry points have their return type expanded within a JS_PUBLIC_API() macro call, to get the right Windows secret type qualifiers in the right places for all build variants.
* Callback functions that might be called from a DLL are similarly macroized with JS_STATIC_DLL_CALLBACK (if the function otherwise would be static to hide its name) or JS_DLL_CALLBACK (this macro takes no type argument; it should be used after the return type and before the function name).

= Data Types and Alignments =

* As with all Mozilla code, SpiderMonkey needs to compile and execute correctly on many platforms, including 64-bits systems.
* JS and NSPR have common roots in the dawn of time (Netscape 2), and the <code>JS_THREADSAFE</code> mode of building SpiderMonkey depends on NSPR, so reading the [http://www.mozilla.org/projects/nspr/reference/html/ NSPR documentation] is well worth your while.
* Not all 64-bit systems use the same integer type model: some are "LP64" (long and pointer are 64 bits, int is 32 bits), while others are "LLP64" (only long long and pointer are 64 bits; long and int are 32 bits).
* Use size_t for unsigned number of bytes variables, ptrdiff_t for signed pointer subtraction results. In particular, do not use uintN, which is just shorthand for unsigned int, and so may not be big enough.

= Header files =

== #ifndef wrappers ==

Use this exact form for #ifndef wrappers in header files:

#ifndef <guard>
#define <guard>
...
#endif // <guard>

GCC and clang recognize this idiom and avoid re-reading headers that use it. Don't put any code before the #ifndef or after the #endif, and don't put anything else in the #ifndef, otherwise the optimization will be thwarted and the file will be multiply-included. (Check with the -H option if you want to be sure.)

Include guards should be named by determining the fully-qualified include path,
then substituting _ for '/' and '.' and '-' in it. For example, js/src/vm/Stack-inl.h's guard is vm_Stack_inl_h_, and js/public/Vector.h's guard is js_Vector_h (because its include path is js/Vector.h).

== #include paths ==

All #include statements should use a fully-qualified (within SpiderMonkey) path, even if it's not necessary. For example, this:

#include "vm/Stack.h"

not:

#include "Stack.h"

This keeps things consistent and helps with the ordering.

For headers in js/public/, the prefix is "js/", e.g.:

#include "js/Vector.h"

For headers in mfbt/, the prefix is "mozilla/", e.g.:

#include "mozilla/Assertions.h"

== #include ordering ==

The following order is used for module X:
* If X-inl.h exists, it goes first. (And X-inl.h's first #include should be X.h.) Otherwise, X.h goes first. This rule ensures that X.h and X-inl.h both #include all the headers that they need themselves.
* mozilla/*.h
* <*.h>
* js*.h
* */*.h (this includes the public JSAPI headers in js/public/*.h which should be included using the form js/*.h)
* js*inlines.h
* */*-inl.h.

Keep (case-insensitive) lexicographic order with each section.

The presence of conditionally-compiled #include statements complicates thing. If you have a single #include statement within a #if/#ifdef/#ifndef block, placing the block in the appropriate section is straightforward. If you have multiple #include statements within a block, use your judgment as to where the best place for it is.

Example for X.cpp:

#include "X.h" // put "X-inl.h" instead, if it exists

#include "mozilla/HashFunctions.h"

#include <string.h>

#include "jsbar.h"
#ifdef BAZ
# include "jsbaz.h"
#endif
#include "jscaz.h"

#include "ds/Baz.h"
#include "js/Bar.h"
#include "vm/Bat.h"

#include "jssqueeinlines.h"
#include "jswoot-inl.h"

#include "frontend/Thingamabob-inl.h"
#include "vm/VirtualReality-inl.h"

= C++ =

== Namespaces ==

* Public functions and types should be in the JS:: namespace, in preference to the old JS/JS_ name prefixes.
* Library-private and friend functions should be in the js:: namespace, in preference to the old js_ name prefix.
* Compile-time-evaluated functions (i.e., template meta-functions) should be in 'js::tl::', the "template library" namespace, to avoid collision with their runtime counterparts.
* In SpiderMonkey .cpp files, it is okay to have 'using namespace js;', but it is not okay to do the same with any other namespace, like JS:: or mozilla::. These can introduce ambiguities that come and go depending on which .cpp files the build system decides to unify.
* If you do have names in JS:: that should be readily available throughout SpiderMonkey, you may add a 'using' declaration to js/src/NamespaceImports.h.
* Avoid unnamed namespaces unless they are necessary to give a class's members internal linkage. Although the C++ standard officially deprecates 'static' on functions, 'static' has the following advantages over unnamed namespaces:
** It is difficult to name functions in unnamed namespaces in gdb.
** Static says "this is a translation-unit-local helper function" on the function, without having to look around for an enclosing "namespace {".

== Enums ==

Older code uses SHOUT_REALLY_LOUD for enum values, newer code uses InterCaps. Enums should be preferred to boolean arguments for ease of understanding at the invocation site.

== Classes ==

* Align the braces of a class/struct/enum definition like this:
class JSObject
{
...
}
* Member variable names, private or public, should be decorated with a trailing '_'.
class Fail
{
size_t capacity; // common
T* begin_; // better, gravitate toward this
}
Sometimes a canonical argument name may conflict with a member name. In this case, one can disambiguate with "this->", although such explicit qualification should only be added when necessary:
class C
{
size_t count;
bool fresh;
void change(size_t count) {
this->count = count;
this->fresh = false; // verbose and unnecessary
}
};
* Prefer inline functions to macros.
* We build with C++ exceptions disabled, so most of the <code>std</code> namespace is off-limits, including STL containers. The exception is <code><algorithm></code>, which is mostly OK to use. You can use MFBT. We have some STL-like containers that are used basically everywhere (see js::Vector, js::HashMap, etc.)

=== Initializer lists ===

Initializer lists can break in one of two ways. The first may be preferable when constructors take few arguments:

class Ninja : public WeaponWeilder, public Camouflagible,
public Assassinatable, public ShapeShiftable
{
Ninja() : WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

The other permitted style mitigates longer-identifiers-squishing-text-against-the-right-side-of-the-screen-syndrome by using a half-indented colon:

class Ninja
: public WeaponWeilder, public Camouflagible, public Assassinatable,
public ShapeShiftable
{
Ninja()
: WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

=== Inline methods ===

If the method in question fits on one line and is branch free, do a one liner:

class Eater
{
void eat(Eaten &other) { other.setConsumed(); }
};

If it's too long, put the type, declarator including formals (unless they overflow), and left brace all on the first line:

class Eater
{
Food* obtainFoodFromEatery(Eatery &eatery) {
if (!eatery.hasFood())
return NULL;
return eatery.purchaseFood();
}
};

For out-of-line inlines (when the definitions are too unwieldy to place in the class definition) use the inline keyword as an indicator that there's an out-of-line inline definition:

class SpaceGoo
{
inline BlobbyWrapper* enblob(Entity &other);
};

inline BlobbyWrapper*
SpaceGoo::enblob(Entity &other)
{
/* ... */
}

== References ==

* [https://developer.mozilla.org/en/Mozilla_Coding_Style_Guide Mozilla's coding style guide].
* [http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml Google's C++ coding style guide].

= Exceptions to this coding style =

SpiderMonkey contains some code imported from other projects, e.g. ctypes/libffi/, that is minimally modified. Such code does not have to follow SpiderMonkey style.

Modules/Core

2016-07-07T21:43:07Z

Jorend: add Dan Gohman to JS engine module

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

They may:

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

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

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

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

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

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

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

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

{{Module
|name=Cookies and Permissions
|description=
|owner=Monica Chew
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-tech-network
|source_dirs=extensions/cookie/, netwerk/cookie/
|url=
|components=Core::Networking: Cookies
}}
{{Module
|name=Cycle Collector
|description=Code to break and collect objects within reference cycles
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]
|peers=Peter Van der Beken, Olli Pettay, David Baron
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers
|components=Core::XPCOM
|group=dev-platform
}}
{{Module
|name=docshell
|description=
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]
|group=dev-tech-layout
|source_dirs=docshell/, uriloader/
|url=
|components=Core::Document Navigation
}}

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

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

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

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

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

{{Module
|name=Editor
|description=
|owner=
|peers=
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

{{Module
|name=Embedding
|description=
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]
|group=dev-embedding
|source_dirs=embedding/
|url=
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging
}}

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

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

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

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

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

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

{{Module
|name=GTK Embedding Widget
|description=Gtk Widget for embedding Mozilla into Gtk applications
|owner=Marco Pesenti Gritti
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:dougt@mozilla.com Doug Turner]
|group=dev-embedding
|source_dirs=
|url=
|components=Core::Embedding: GTK Widget
}}

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

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

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

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

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

{{Module
|name=IPC
|description=Message-passing between threads and processes
|owner=[mailto:wmccloskey@mozilla.com Bill McCloskey]
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:jld@mozilla.com Jed Davis]
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{Module
|name=Qt-based gfx and widget
|description=Qt-based rendering and widget code
|owner=[mailto:romaxa@gmail.com Oleg Romashin]
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:dougt@mozilla.com Doug Turner]
|group=dev-tech-widget
|source_dirs=widget/qt/
|url=
|components=Core::Widget: Qt
}}

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

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:ttaubert@mozilla.com Tim Taubert]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com David Keeler]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM, Core::Security: UI
}}

{{Module
|name=Static analysis & rewriting for C++
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:michael@thelayzells.com Michael Layzell], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas]
|group=dev-platform
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools
|url=
|components=Core::Rewriting & Analysis
}}
{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:bent.mozillla@gmail.com Ben Turner]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:cam@mcc.id.au Cameron McCormack]
|group=dev-tech-layout
|source_dirs=layout/style/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=Tamarin
|description=VM for ActionScript and JavaScript
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]
|group=dev-tech-js-engine
|source_dirs=js/tamarin
|url=http://www.mozilla.org/projects/tamarin/
http://wiki.mozilla.org/tamarin/
http://hg.mozilla.org/tamarin-central/
http://hg.mozilla.org/tamarin-tracing/
|components=Tamarin
}}

{{Module
|name=Test Harness
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill, Marionette, Firefox UI Tests. Requests for new harnesses should go to Testing::General.
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), Rob Campbell (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (mozmill, Firefox UI tests), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette) [mailto:dminor@mozilla.com Dan Minor], [mailto:mjzffr@gmail.com Maja Frydrychowicz] (Firefox UI tests), [mailto:spolk@mozilla.com Syd Polk] (Firefox UI tests)

|group=dev-quality
|source_dirs=/testing
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js
}}

{{Module
|name=Testing Infrastructure
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker
|owner=[mailto:jmaher@mozilla.com Joel Maher]
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], Rob Campbell, [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]
|group=dev-quality
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::Infrastructure
}}

{{Module
|name=JS Marionette
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye>
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk>
|source_dirs=gaia/tests/jsmarionette
|components=Testing::JSMarionette
|group=dev-gaia
}}

{{Module
|name=XPCShell Test Harness
|description=The XPCShell Harness
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]
|peers=[mailto:jmaher@mozilla.com Joel Maher]
|source_dirs=testing/xpcshell
|components=Testing::XPCShell Harness
}}

{{Module
|name=Update Service
|description=server code for Mozilla Update services (aus, addons, pfs)
|owner=Mike Morgan
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]
|group=dev-amo
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/
|url=http://wiki.mozilla.org/wiki/AMO
|components=AUS::Administration, AUS::Systems
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:padenot@mozilla.com Paul Adenot], [mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:ehugg@cisco.com Ethan Hugg], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|group=dev-media
|source_dirs=N/A (see submodules "WebRTC Media" and "WebRTC Signaling")
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC
}}

{{Module
|name=Widget
|description=
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup
}}

{{Module
|name=Widget - Android
|description=The Android Port
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]
|peers=[mailto:jwillcox@mozilla.com James Willcox]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=supported X widgetry and gfx
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - OS X
|description= Gecko's OS X compatibility layer.
|owner=[mailto:mstange@themasta.com Markus Stange]
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widgets and desktop integration
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:dougt@mozilla.com Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XBL
|description=eXtensible Binding Language
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley]
|group=dev-tech-xbl
|source_dirs=dom/xbl/
|url=http://www.mozilla.org/projects/xbl/
|components=Core::XBL
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|peers=[https://mozillians.org/en-US/u/dougt/ Doug Turner], [https://mozillians.org/en-US/u/bsmedberg/ Benjamin Smedberg]
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|peersemeritus=[mailto:gal@uci.edu Andreas Gal]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:me@kylehuey.com Kyle Huey]
|peers=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XPInstall
|description=
|owner=[mailto:dveditz@mozilla.com Dan Veditz]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|group=dev-tech-xpinstall
|source_dirs=xpinstall/
|url=
|components=Core::Installer: XPInstall Engine
}}

{{Module
|name=xptcall
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]
|group=dev-xpcom
|source_dirs=xpcom/reflect/xptcall/
|url=http://www.mozilla.org/scriptable/xptcall-faq.html
|components=
}}

{{Module
|name=XPToolkit
|description=Cross-platform user interface toolkit
|owner=
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]
|group=dev-tech-xul
|source_dirs=dom/xul/, layout/xul/
|url=http://www.mozilla.org/xpfe/
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=XTF
|description=eXtensible Tag Framework
|owner=
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xbl
|source_dirs=content/xtf/, layout/xtf/
|url=http://www.croczilla.com/bits_and_pieces/xtf/
|components=Core::XTF
}}

{{Module
|name=Sandboxing
|description=Cross platform sandboxing
|owner=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|peers=[mailto:bowen@mozilla.com Bob Owen], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes], [mailto:gDestuynder@mozilla.com Guillaume Destuynder], [mailto:bsmedberg@mozilla.com Benjamin Smedberg], [mailto:jld@mozilla.com Jed Davis]
|group=dev-platform
|source_dirs=security/sandbox
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bowen@mozilla.com Bob Owen]
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes], [mailto:jimm@mozilla.com Jim Mathies]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]
|peers=
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux & B2G
|description=Sandboxing for the Linux & B2G platforms
|owner=[mailto:jhector@mozilla.com Julian Hector]
|peers=[mailto:jld@mozilla.com Jed Davis] [mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:gps@mozilla.com Gregory Szorc]
|peers=Same as Build Config plus [mailto:nalexander@mozilla.com Nicholas Alexander].
|group=dev-builds
|components=Core::Build Config
}}

{{Module
|name=WebRTC Media
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ehugg@cisco.com Ethan Hugg], [mailto:pkerr@mozilla.com Paul Kerr]
|group=dev-media
|source_dirs=/media/webrtc, /dom/media/webrtc
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Audio/Video)
}}

{{Module
|name=WebRTC Signaling
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling
|owner=[mailto:bcampen@mozilla.com Byron Campen]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|group=dev-media
|source_dirs=/media/peerconnection, /dom/media/peerconnection ''(note: file reorg underway)''
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Signaling)
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::File Handling
Core::Find Backend
Core::Gecko Profiler
Core::General
Core::HTML: Form Submission
Core::History: Global
Core::Image Blocking
Core::JavaScript Debugging APIs
Core::Localization
Core::Nanojit
Core::Networking: Domain Lists
Core::Print Preview
Core::Printing: Output
Core::Printing: Setup
Core::Profile: BackEnd
Core::Profile: Migration
Core::Profile: Roaming
Core::QuickLaunch (AKA turbo mode)
Core::Rewriting and Analysis
Core::Selection
Core::Serializers
Core::Spelling checker
Core::Tracking
Core::Web Services
Core::WebDAV
Core::Widget: OS/2
Core::Widget: Photon
Core::X-remote
Core::XForms
Core::XUL
</pre>
</noinclude>

Modules/Core

2015-10-21T13:01:38Z

Jorend: add [:arai] to JS team

<noinclude>
'''Do not edit this page''' unless either:

# you are a module owner who is:
#* altering the list of peers in your module
#* adding or removing a sub-module
#* changing the owner of one of your sub-modules; or
# you have agreed a change of owner or module addition/deletion with the Module Ownership Module group, probably via [https://www.mozilla.org/about/forums/#governance mozilla.governance].
</noinclude>
{{Module
|name=Accessibility
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:ginn.chen@oracle.com Ginn Chen], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe]
|group=dev-accessibility
|source_dirs=accessible/
|url=http://www.mozilla.org/access/
|components=Core::Disability Access APIs
}}

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

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

{{Module
|name=Build Config
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:benjamin@smedbergs.us Benjamin Smedberg] (:bsmedberg)
|group=dev-builds
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/
|url=http://www.mozilla.org/build/
|components=Core::Build Config
}}

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

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

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

{{Module
|name=Cookies and Permissions
|description=
|owner=[mailto:mchew@mozilla.com Monica Chew]
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-tech-network
|source_dirs=extensions/cookie/, netwerk/cookie/
|url=
|components=Core::Networking: Cookies
}}
{{Module
|name=Cycle Collector
|description=Code to break and collect objects within reference cycles
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]
|peers=Peter Van der Beken, Olli Pettay, David Baron
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers
|components=Core::XPCOM
|group=dev-platform
}}
{{Module
|name=docshell
|description=
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]
|group=dev-tech-layout
|source_dirs=docshell/, uriloader/, webshell/
|url=
|components=Core::Document Navigation
}}

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

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

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

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

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

{{Module
|name=Editor
|description=
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

{{Module
|name=Embedding
|description=
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]
|group=dev-embedding
|source_dirs=embedding/
|url=
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging
}}

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

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

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

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

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

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

{{Module
|name=GTK Embedding Widget
|description=Gtk Widget for embedding Mozilla into Gtk applications
|owner=[mailto:marco@gnome.org Marco Pesenti Gritti]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:dougt@meer.net Doug Turner]
|group=dev-embedding
|source_dirs=
|url=
|components=Core::Embedding: GTK Widget
}}

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

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

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

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

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

{{Module
|name=IPC
|description=Message-passing between threads and processes
|owner=[mailto:wmccloskey@mozilla.com Bill McCloskey]
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:jld@mozilla.com Jed Davis]
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{Module
|name=NSPR
|description=Netscape Portable Runtime
|owner=[mailto:nelson@bolyard.com Nelson Bolyard], [mailto:wtc@google.com Wan-Teh Chang]
|peers=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]
|group=dev-tech-nspr
|source_dirs=nsprpub/
|url=http://www.mozilla.org/projects/nspr/
http://www.mozilla.org/projects/nspr/reference/html/
http://www.mozilla.org/projects/nspr/release-notes/
|components=NSPR
}}

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

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

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

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

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

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

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

{{Module
|name=Qt-based gfx and widget
|description=Qt-based rendering and widget code
|owner=[mailto:romaxa@gmail.com Oleg Romashin]
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:doug.turner@gmail.com Doug Turner]
|group=dev-tech-widget
|source_dirs=widget/qt/
|url=
|components=Core::Widget: Qt
}}

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

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com David Keeler]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM, Core::Security: UI
}}

{{Module
|name=Static analysis & rewriting for C++
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:michael@thelayzells.com Michael Layzell], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas]
|group=dev-platform
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools
|url=
|components=Core::Rewriting & Analysis
}}
{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:bent.mozillla@gmail.com Ben Turner]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:cam@mcc.id.au Cameron McCormack]
|group=dev-tech-layout
|source_dirs=layout/style/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=Tamarin
|description=VM for ActionScript and JavaScript
|owner=[mailto:edwsmith@adobe.com Edwin Smith], [mailto:jodyer@adobe.com Jeff Dyer]
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]
|group=dev-tech-js-engine
|source_dirs=js/tamarin
|url=http://www.mozilla.org/projects/tamarin/
http://wiki.mozilla.org/tamarin/
http://hg.mozilla.org/tamarin-central/
http://hg.mozilla.org/tamarin-tracing/
|components=Tamarin
}}

{{Module
|name=Test Harness
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill and Marionette. Requests for new harnesses should go to Testing::General.
|owner=[mailto:ted@mozilla.com Ted Mielczarek]
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), [mailto:rcampbell@mozilla.com Rob Campbell] (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (mozmill), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette) [mailto:dminor@mozilla.com Dan Minor]
|group=dev-quality
|source_dirs=/testing
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js
}}

{{Module
|name=Testing Infrastructure
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker
|owner=[mailto:jmaher@mozilla.com Joel Maher]
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], [mailto:rcampbell@mozilla.com Rob Campbell], [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]
|group=dev-quality
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::Infrastructure
}}

{{Module
|name=JS Marionette
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye>
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk>
|source_dirs=gaia/tests/jsmarionette
|components=Testing::JSMarionette
|group=dev-gaia
}}

{{Module
|name=XPCShell Test Harness
|description=The XPCShell Harness
|owner=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]
|peers=[mailto:jmaher@mozilla.com Joel Maher]
|source_dirs=testing/xpcshell
|components=Testing::XPCShell Harness
}}

{{Module
|name=Update Service
|description=server code for Mozilla Update services (aus, addons, pfs)
|owner=[mailto:morgamic@mozilla.com Mike Morgan]
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]
|group=dev-amo
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/
|url=http://wiki.mozilla.org/wiki/AMO
|components=AUS::Administration, AUS::Systems
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:padenot@mozilla.com Paul Adenot], [mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:ehugg@cisco.com Ethan Hugg], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|group=dev-media
|source_dirs=N/A (see submodules "WebRTC Media" and "WebRTC Signaling")
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC
}}

{{Module
|name=Widget
|description=
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget
}}

{{Module
|name=Widget - Android
|description=The Android Port
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]
|peers=[mailto:jwillcox@mozilla.com James Willcox]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=supported X widgetry and gfx
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - OS X
|description= Gecko's OS X compatibility layer.
|owner=[mailto:mstange@themasta.com Markus Stange]
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widgets and desktop integration
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:dougt@meer.net Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XBL
|description=eXtensible Binding Language
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley]
|group=dev-tech-xbl
|source_dirs=dom/xbl/
|url=http://www.mozilla.org/projects/xbl/
|components=Core::XBL
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:jag@tty.nl Peter Annema], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|peers=[https://mozillians.org/en-US/u/dougt/ Doug Turner], [https://mozillians.org/en-US/u/bsmedberg/ Benjamin Smedberg]
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:gal@uci.edu Andreas Gal], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:me@kylehuey.com Kyle Huey]
|peers=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XPInstall
|description=
|owner=[mailto:dveditz@cruzio.com Dan Veditz]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|group=dev-tech-xpinstall
|source_dirs=xpinstall/
|url=
|components=Core::Installer: XPInstall Engine
}}

{{Module
|name=xptcall
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]
|group=dev-xpcom
|source_dirs=xpcom/reflect/xptcall/
|url=http://www.mozilla.org/scriptable/xptcall-faq.html
|components=
}}

{{Module
|name=XPToolkit
|description=Cross-platform user interface toolkit
|owner=
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:hyatt@mozilla.org Dave Hyatt], [mailto:jag@tty.nl Peter Annema], [mailto:Jan.Varga@gmail.com Jan Varga]
|group=dev-tech-xul
|source_dirs=dom/xul/, layout/xul/
|url=http://www.mozilla.org/xpfe/
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=XTF
|description=eXtensible Tag Framework
|owner=
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xbl
|source_dirs=content/xtf/, layout/xtf/
|url=http://www.croczilla.com/bits_and_pieces/xtf/
|components=Core::XTF
}}

{{Module
|name=Sandboxing
|description=Cross platform sandboxing
|owner=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]
|peers=[mailto:bowen@mozilla.com Bob Owen], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes], [mailto:gDestuynder@mozilla.com Guillaume Destuynder], [mailto:bsmedberg@mozilla.com Benjamin Smedberg], [mailto:jld@mozilla.com Jed Davis]
|group=dev-platform
|source_dirs=security/sandbox
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bowen@mozilla.com Bob Owen]
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=
|peers=
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux & B2G
|description=Sandboxing for the Linux & B2G platforms
|owner=
|peers=[mailto:jld@mozilla.com Jed Davis]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:gps@mozilla.com Gregory Szorc]
|peers=Same as Build Config plus [mailto:nalexander@mozilla.com Nicholas Alexander].
|group=dev-builds
|components=Core::Build Config
}}

{{Module
|name=WebRTC Media
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ehugg@cisco.com Ethan Hugg], [mailto:pkerr@mozilla.com Paul Kerr]
|group=dev-media
|source_dirs=/media/webrtc, /dom/media/webrtc
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Audio/Video)
}}

{{Module
|name=WebRTC Signaling
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling
|owner=[mailto:bcampen@mozilla.com Byron Campen]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]
|group=dev-media
|source_dirs=/media/peerconnection, /dom/media/peerconnection ''(note: file reorg underway)''
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC (Signaling)
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::Event Handling
Core::File Handling
Core::Find Backend
Core::Gecko Profiler
Core::General
Core::HTML: Form Submission
Core::History: Global
Core::Identity
Core::Image Blocking
Core::JavaScript Debugging APIs
Core::Localization
Core::Nanojit
Core::Networking: Domain Lists
Core::Print Preview
Core::Printing: Output
Core::Printing: Setup
Core::Profile: BackEnd
Core::Profile: Migration
Core::Profile: Roaming
Core::QuickLaunch (AKA turbo mode)
Core::Rewriting and Analysis
Core::Selection
Core::Serializers
Core::Spelling checker
Core::Tracking
Core::Web Services
Core::WebDAV
Core::Widget: OS/2
Core::Widget: Photon
Core::X-remote
Core::XForms
Core::XUL
</pre>
</noinclude>

Modules/Core

2015-04-30T19:05:59Z

Jorend: rearrange list of JS peers to put inactive peers at the end; add Eric Faust and Nick Fitzgerald

<noinclude>
'''Do not edit this page''' unless either:

# you are a module owner who is:
#* altering the list of peers in your module
#* adding or removing a sub-module
#* changing the owner of one of your sub-modules; or
# you have agreed a change of owner or module addition/deletion with the Module Ownership Module group, probably via [https://www.mozilla.org/about/forums/#governance mozilla.governance].
</noinclude>
{{Module
|name=Accessibility
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:ginn.chen@oracle.com Ginn Chen], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe]
|group=dev-accessibility
|source_dirs=accessible/
|url=http://www.mozilla.org/access/
|components=Core::Disability Access APIs
}}

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

{{Module
|name=Build and Release Tools
|description=Tools related to build and release automation and configuration of release builds.
|owner=[mailto:nrthomas@gmail.com Nick Thomas]
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:cmp@mozilla.org Chase Phillips], [mailto:mozpreed@sigkill.com John Paul Reed], [mailto:robert@roberthelmer.com Robert Helmer]
|group=dev-builds
|source_dirs=tools/botrunner.py, tools/build-environment/, tools/build/, tools/buildbot-configs/, tools/buildbot/, tools/buildbotcustom/, tools/l10n/, tools/MozBuild/, tools/patcher-configs/, tools/patcher/, tools/release/, tools/tinderbox-configs/, tools/tinderbox/, tools/update-packaging/, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/
|url=
|components=mozilla.org::Release Engineering, mozilla.org::Release Engineering: Custom Builds
}}

{{Module
|name=Build Config
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:benjamin@smedbergs.us Benjamin Smedberg] (:bsmedberg)
|group=dev-builds
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/
|url=http://www.mozilla.org/build/
|components=Core::Build Config
}}

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

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

{{Module
|name=Content Security
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), and Safe Browsing.
|owner=[mailto:sstamm@mozilla.com Sid Stamm], [mailto:gpascutto@mozilla.com Gian-Carlo Pascutto]
|peers=[mailto:grobinson@mozilla.com Garrett Robinson], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]
|group=dev-security
|source_dirs=dom/security
|components=Core::DOM: Security
}}

{{Module
|name=Cookies and Permissions
|description=
|owner=[mailto:mchew@mozilla.com Monica Chew]
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]
|group=dev-tech-network
|source_dirs=extensions/cookie/, netwerk/cookie/
|url=
|components=Core::Networking: Cookies
}}
{{Module
|name=Cycle Collector
|description=Code to break and collect objects within reference cycles
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]
|peers=Peter Van der Beken, Olli Pettay, David Baron
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers
|components=Core::XPCOM
|group=dev-platform
}}
{{Module
|name=docshell
|description=
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]
|group=dev-tech-layout
|source_dirs=docshell/, uriloader/, webshell/
|url=
|components=Core::Document Navigation
}}

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

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

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

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

{{Module
|name=Editor
|description=
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

{{Module
|name=Embedding
|description=
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]
|group=dev-embedding
|source_dirs=embedding/
|url=
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging
}}

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

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

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

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

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

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

{{Module
|name=GTK Embedding Widget
|description=Gtk Widget for embedding Mozilla into Gtk applications
|owner=[mailto:marco@gnome.org Marco Pesenti Gritti]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:dougt@meer.net Doug Turner]
|group=dev-embedding
|source_dirs=
|url=
|components=Core::Embedding: GTK Widget
}}

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

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

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

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

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

{{Module
|name=IPC
|description=Message-passing between threads and processes
|owner=[mailto:cjones@mozilla.com Chris Jones]
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner]
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{Module
|name=NSPR
|description=Netscape Portable Runtime
|owner=[mailto:nelson@bolyard.com Nelson Bolyard], [mailto:wtc@google.com Wan-Teh Chang]
|peers=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]
|group=dev-tech-nspr
|source_dirs=nsprpub/
|url=http://www.mozilla.org/projects/nspr/
http://www.mozilla.org/projects/nspr/reference/html/
http://www.mozilla.org/projects/nspr/release-notes/
|components=NSPR
}}

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

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

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

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

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

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

{{Module
|name=Qt-based gfx and widget
|description=Qt-based rendering and widget code
|owner=[mailto:romaxa@gmail.com Oleg Romashin]
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:doug.turner@gmail.com Doug Turner]
|group=dev-tech-widget
|source_dirs=widget/qt/
|url=
|components=Core::Widget: Qt
}}

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

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:dkeeler@mozilla.com David Keeler]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:wtc@google.com Wan-Teh Chang]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM, Core::Security: UI
}}

{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:mak77@bonardo.net Marco Bonardo]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:bent.mozillla@gmail.com Ben Turner]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:cam@mcc.id.au Cameron McCormack]
|group=dev-tech-layout
|source_dirs=layout/style/
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System
|components=Core::CSS Parsing and Computation
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]
|group=dev-tech-svg
|source_dirs=dom/svg/, layout/svg/, dom/smil/
|url=https://developer.mozilla.org/en-US/docs/Web/SVG
|components=Core::SVG
}}

{{Module
|name=Tamarin
|description=VM for ActionScript and JavaScript
|owner=[mailto:edwsmith@adobe.com Edwin Smith], [mailto:jodyer@adobe.com Jeff Dyer]
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]
|group=dev-tech-js-engine
|source_dirs=js/tamarin
|url=http://www.mozilla.org/projects/tamarin/
http://wiki.mozilla.org/tamarin/
http://hg.mozilla.org/tamarin-central/
http://hg.mozilla.org/tamarin-tracing/
|components=Tamarin
}}

{{Module
|name=Test Harness
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill and Marionette. Requests for new harnesses should go to Testing::General.
|owner=[mailto:ted@mozilla.com Ted Mielczarek]
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), [mailto:rcampbell@mozilla.com Rob Campbell] (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (mozmill), [mailto:mdas@mozilla.com Malini Das] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette) [mailto:dminor@mozilla.com Dan Minor]
|group=dev-quality
|source_dirs=/testing
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js
}}

{{Module
|name=Testing Infrastructure
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker
|owner=[mailto:jmaher@mozilla.com Joel Maher]
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], [mailto:rcampbell@mozilla.com Rob Campbell], [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]
|group=dev-quality
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::Infrastructure
}}

{{Module
|name=JS Marionette Harness and Tools
|description=Test harness and associated tools for running marionette tests on NodeJS (submodule of Test Infrastructure)
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye>
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk>, [mailto:mike@bocoup.com Mike Pennisi] <jugglinmike>, [mailto:evanxd@mozilla.com Evan Tseng] <evanxd>
|source_dirs=These are all mozilla-b2g github repos: [https://github.com/mozilla-b2g/marionette-js-runner Marionette JS Runner], [https://github.com/mozilla-b2g/mocha-json-proxy Mocha JSON Proxy], [https://github.com/mozilla-b2g/mocha-tbpl-reporter Mocha TBPL Reporter], [https://github.com/mozilla-b2g/marionette-js-client Marionette JS Client], [https://github.com/mozilla-b2g/sockit-to-me Sockit To Me], [https://github.com/mozilla-b2g/marionette-apps Marionette Apps], [https://github.com/mozilla-b2g/marionette-js-logger Marionette JS Logger], [https://github.com/mozilla-b2g/marionette-b2gdesktop-host Marionette B2G Desktop Host], [https://github.com/mozilla-b2g/marionette-firefox-host Marionette Firefox Host], [https://github.com/mozilla-b2g/marionette-profile-builder Marionette Profile Builder], [https://github.com/mozilla-b2g/mozilla-profile-builder Mozilla Profile Builder]
|components=Testing::JSMarionette
|group=dev-gaia
}}

{{Module
|name=XPCShell Test Harness
|description=The XPCShell Harness
|owner=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]
|peers=[mailto:jmaher@mozilla.com Joel Maher]
|source_dirs=testing/xpcshell
|components=Testing::XPCShell Harness
}}

{{Module
|name=Update Service
|description=server code for Mozilla Update services (aus, addons, pfs)
|owner=[mailto:morgamic@mozilla.com Mike Morgan]
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]
|group=dev-amo
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/
|url=http://wiki.mozilla.org/wiki/AMO
|components=AUS::Administration, AUS::Systems
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=Web Audio
|description=Support for the W3C Web Audio API specification.
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:padenot@mozilla.com Paul Adenot]
|group=dev-platform
|source_dirs=dom/media/webaudio
|url=https://wiki.mozilla.org/Web_Audio_API
|components=Core::Web Audio
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access (on desktop at least)
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:ehugg@cisco.com Ethan Hugg], [mailto:tterriberry@mozilla.com Tim Terriberry], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]
|group=dev-media
|source_dirs=media/webrtc, dom/media/webrtc
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC, Core::WebRTC (Audio/Video), Core::WebRTC (Networking), Core::WebRTC (Signaling)
}}

{{Module
|name=Widget
|description=
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=widget/, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget
}}

{{Module
|name=Widget - Android
|description=The Android Port
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]
|peers=[mailto:jwillcox@mozilla.com James Willcox]
|group=dev-platforms-mobile
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - GTK
|description=supported X widgetry and gfx
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-platform
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - OS X
|description= Gecko's OS X compatibility layer.
|owner=[mailto:smichaud@pobox.com Steven Michaud]
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:mstange@themasta.com Markus Stange], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widgets and desktop integration
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:dougt@meer.net Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XBL
|description=eXtensible Binding Language
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley]
|group=dev-tech-xbl
|source_dirs=dom/xbl/
|url=http://www.mozilla.org/projects/xbl/
|components=Core::XBL
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback]
|group=dev-tech-xml
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:jag@tty.nl Peter Annema], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|peers=[https://mozillians.org/en-US/u/dougt/ Doug Turner], [https://mozillians.org/en-US/u/bsmedberg/ Benjamin Smedberg]
|group=dev-platform
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=Deep Magic
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:gal@uci.edu Andreas Gal], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.
|owner=[mailto:me@kylehuey.com Kyle Huey]
|peers=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XPInstall
|description=
|owner=[mailto:dveditz@cruzio.com Dan Veditz]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|group=dev-tech-xpinstall
|source_dirs=xpinstall/
|url=
|components=Core::Installer: XPInstall Engine
}}

{{Module
|name=xptcall
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]
|group=dev-xpcom
|source_dirs=xpcom/reflect/xptcall/
|url=http://www.mozilla.org/scriptable/xptcall-faq.html
|components=
}}

{{Module
|name=XPToolkit
|description=Cross-platform user interface toolkit
|owner=
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:hyatt@mozilla.org Dave Hyatt], [mailto:jag@tty.nl Peter Annema], [mailto:Jan.Varga@gmail.com Jan Varga]
|group=dev-tech-xul
|source_dirs=dom/xul/, layout/xul/
|url=http://www.mozilla.org/xpfe/
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=dom/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=XTF
|description=eXtensible Tag Framework
|owner=
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xbl
|source_dirs=content/xtf/, layout/xtf/
|url=http://www.croczilla.com/bits_and_pieces/xtf/
|components=Core::XTF
}}

{{Module
|name=Sandboxing - Windows
|description=Sandboxing for the Windows platform
|owner=[mailto:bowen@mozilla.com Bob Owen]
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]
|group=dev-platform
|source_dirs=security/sandbox/win
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - OSX
|description=Sandboxing for the OSX platform
|owner=[mailto:smichaud@mozilla.com Steven Michaud]
|peers=[mailto:areinald@mozilla.com Andre Reinald ]
|group=dev-platform
|source_dirs=security/sandbox/mac
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

{{Module
|name=Sandboxing - Linux & B2G
|description=Sandboxing for the Linux & B2G platforms
|owner=[mailto:jld@mozilla.com Jed Davis]
|peers=[mailto:gDestuynder@mozilla.com Guillaume Destuynder]
|group=dev-platform
|source_dirs=security/sandbox/linux
|url=https://wiki.mozilla.org/Security/Sandbox
|components=Core::Security: Process Sandboxing
}}

===Submodules===
{{Module
|name=Build Config - Fennec
|description=Submodule of the build config covering Fennec's build system in mobile/android.
|owner=[mailto:gps@mozilla.com Gregory Szorc]
|peers=Same as Build Config plus [mailto:nalexander@mozilla.com Nicholas Alexander].
|group=dev-builds
|components=Core::Build Config
}}

<noinclude>

===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::Event Handling
Core::File Handling
Core::Find Backend
Core::Gecko Profiler
Core::General
Core::HTML: Form Submission
Core::History: Global
Core::Identity
Core::Image Blocking
Core::JavaScript Debugging APIs
Core::Localization
Core::Nanojit
Core::Networking: Domain Lists
Core::Print Preview
Core::Printing: Output
Core::Printing: Setup
Core::Profile: BackEnd
Core::Profile: Migration
Core::Profile: Roaming
Core::QuickLaunch (AKA turbo mode)
Core::Rewriting and Analysis
Core::Selection
Core::Serializers
Core::Spelling checker
Core::Tracking
Core::Video/Audio
Core::Web Services
Core::WebDAV
Core::Widget: OS/2
Core::Widget: Photon
Core::X-remote
Core::XForms
Core::XUL
</pre>
</noinclude>

JavaScript:SpiderMonkey:Coding Style

2014-10-01T22:41:13Z

Jorend: /* Control Flow */ Add the jorendorff rule

= Functions =

* Public function names begin with JS_ followed by capitalized "intercaps", e.g. JS_NewObject.
* Extern but library-private function names use a js_ prefix and mixed case, e.g. js_SearchScope.
* Most static function names have unprefixed, mixed-case names: GetChar.
* But static native methods of JS objects have lowercase, underscore-separated or intercaps names, e.g., str_indexOf.
* Function return types are on a separate line preceding the function name.
* Function braces go on the line following the function name.
void DoThis() /* bad */
{
...
}
void
DoThis() /* OK */
{
...
}

= Other Symbols =

* Library-private and static data use underscores, not intercaps (but library-private data do use a js_ prefix).
* Scalar type names are lowercase and js-prefixed: jsdouble.
* Aggregate type names are JS-prefixed and mixed-case: JSObject.
* Macros are generally ALL_CAPS and underscored, to call out potential side effects, multiple uses of a formal argument, etc. Line continuation characters should all line up, in column 79 if that exceeds the width of all the macro text. Macro parameters should be of the form name_ (instead of something like __name).

= Indentation =

* Use spaces, not tabs. There should be no tabs in source files.
* Four spaces of indentation per statement nesting level.
* "<code>case L:</code>" labels in <code>switch</code> statements count as half of a nesting level, so indent two spaces, with the labeled statements indenting two more for a standard four spaces indentation from <code>switch</code> to a case-controlled statement.
switch (discriminant) {
case L1:
DoSomething();
. . .
}
* Function arguments that overflow the first line of the call expression should be aligned to underhang the first argument (to start in overflow lines in the column after the opening parenthesis).
JS_SetContext(rt, /* bad */
cx);
JS_SetContext(rt, /* OK */
cx);

= Whitespace in declarations =

These rules are inconsistently applied. Be consistent with the code you're editing rather than adhere too closely to these guidelines!

* In a declaration of a pointer, the <code>*</code> goes with the variable name:
char* s; /* bad */
char *s; /* OK */
* Even in the return type of a method:
class JSString
{
...
JSString* dependentBase() const; /* bad */
JSString * dependentBase() const; /* bad */
JSString *dependentBase() const; /* OK */
...
};
* But in top-level function declarations/definitions, put a line break immediately before the name being declared:
extern const char *
js_GetStringBytes(JSContext *cx, JSString *str); /* OK */
* And put a space in <code>*JS_FASTCALL</code>, because that would be crazy.
extern JSString *JS_FASTCALL /* bad */
js_ConcatStrings(JSContext *cx, JSString *left, JSString *right);
extern JSString * JS_FASTCALL /* OK */
js_ConcatStrings(JSContext *cx, JSString *left, JSString *right);
* In C++ method declarations with default arguments, use spaces and comments like so:
static void
Frob(JSContext *cx, uint32_t defaultValue = 0);
static void
Frob(JSContext *cx, uint32_t defaultValue /* = 0 */)
{
/* ... */
}

= Other whitespace =

* Code should fit within 99 columns; comments should fit within 80 columns; both figures include indentation. Break down lines that are too long by splitting after a binary operator.
* Exception: in a <code>switch</code> statement where each case is a trivially-short statement, it's ok to put the <code>case</code>, the statement, and the <code>break;</code> all on one line.
* Comment <code>/* FALL THROUGH */</code> in place of missing <code>break</code> when intentionally falling through from one case-controlled statement sequence into another, or into the <code>default</code> statements.
* Do not use spaces between a function name and its arguments list, or between an array name and the square bracket. Also, do no use spaces after a bracket. Use a space after a comma to separate arguments.
JS_SetContext ( rt, cx ); /* bad */
JS_SetContext(rt, cx); /* OK */
* Use a space between a C keyword and parentheses.
if(condition) /* bad */
if (condition) /* OK */
* In a conditional, if the consequent (and, if present, the alternate) is a single statement, no braces are used.
if (today == "Tuesday")
puts("I don't have my wallet on me.");
else
puts("I would gladly pay you on Tuesday for a hamburger today.");
However, if ''either'' the consequent or alternate is a block of multiple statements, braces are used on both.
if (canSwingFromWeb) {
p->swingFromWeb();
} else {
JS_ASSERT(p->isSpiderPig());
p->doWhateverSpiderPigDoes();
}
* Conditions with multi-line tests should put the brace on the new line to provide a visual separation between the condition and the body.

types::TypeSet *types = frame.extra(lhs).types;
if (JSOp(*PC) == JSOP_SETPROP && id == types::MakeTypeId(cx, id) &&
types && !types->unknownObject() &&
types->getObjectCount() == 1 &&
types->getTypeObject(0) != NULL &&
!types->getTypeObject(0)->unknownProperties())
{
JS_ASSERT(usePropCache);
types::TypeObject *object = types->getTypeObject(0);
types::TypeSet *propertyTypes = object->getProperty(cx, id, false);
...
} else {
...
}
However, if there is already a visual separation between the condition and the body, putting the { on a new line isn't necessary:

if (forHead->pn_kid1 && NewSrcNote2(cx, cg, SRC_DECL,
(forHead->pn_kid1->isOp(JSOP_DEFVAR))
? SRC_DECL_VAR
: SRC_DECL_LET) < 0) {
return false;
}
* <code>for</code> loop heads go on one line where possible; when not possible, initializer part, update, and termination parts each go on separate lines
for (int i = 0;
i < 5;
i++) { /* bad, could all fit on one line */
doStuff();
}
for (int i = 0; i < 5; i++) /* OK */
doStuff();
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS; ind++) { /* bad */
obj->setSlot(ind, DoubleValue(utcTime));
}
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS;
ind++) { /* OK */
obj->setSlot(ind, DoubleValue(utcTime));
}
* In comments, use one space, not two, between sentences and after a colon.

= Control Flow =

* Minimize indentation using return, break, and continue where appropriate. Prefer return (break, continue) statements to cast out abnormal cases, instead of nesting "if/else" statements and indenting the common cases.
void
MyFunction(int n)
{
if (n) { /* bad */
...
}
}
void
MyFunction(int n)
{
if (!n)
return; /* OK */
...
}

* If an "if" statement controls a "then" clause ending in a return statement, do not use "else" after return.
if (condition) { /* bad */
DoThis();
return;
} else {
DoThat();
}

if (condition) { /* OK */
DoThis();
return;
}
DoThat();

* Avoid similar arbitrary patterns and non-sequiturs:
if (condition) { /* bad */
DoThis();
DoThat();
} else {
CleanUp();
return;
}
DoTheOther();
if (!condition) { /* OK */
CleanUp();
return;
}
DoThis();
DoThat();
DoTheOther();

* Avoid using && or || to mix deciding-whether-to-do-something with error-checking.

if (obj->hasProblems() && !obj->rectify()) /* bad */
return false;

if (obj->hasProblems()) { /* OK */
if (!obj->rectify())
return false;
}

= Comments =

* In C files, always use C style comments. C++ comments are ok otherwise.
* Terminate a comment with a period (so try to make comments be complete sentences).
/* This is a good comment. */
// This is also a good comment.
* For C-style multiline comments, align with any indentation, and start every line with an asterisk. Asterisks stack in the same column. Precede the multiline comment with one empty line unless the prior line ends in a left brace. The first line of the comment contains only leading space followed by <code>/*</code>. Multiline comments should also be bracketed.
<pre>
if (condition) {
/*
* This is a lengthy C-style
* multiline comment.
*/
// This is a length
// C++-style comment
DoYourStuff();
}
</pre>

= Entry Points and Callbacks =

* DLL entry points have their return type expanded within a JS_PUBLIC_API() macro call, to get the right Windows secret type qualifiers in the right places for all build variants.
* Callback functions that might be called from a DLL are similarly macroized with JS_STATIC_DLL_CALLBACK (if the function otherwise would be static to hide its name) or JS_DLL_CALLBACK (this macro takes no type argument; it should be used after the return type and before the function name).

= Data Types and Alignments =

* As with all Mozilla code, SpiderMonkey needs to compile and execute correctly on many platforms, including 64-bits systems.
* JS and NSPR have common roots in the dawn of time (Netscape 2), and the <code>JS_THREADSAFE</code> mode of building SpiderMonkey depends on NSPR, so reading the [http://www.mozilla.org/projects/nspr/reference/html/ NSPR documentation] is well worth your while.
* Not all 64-bit systems use the same integer type model: some are "LP64" (long and pointer are 64 bits, int is 32 bits), while others are "LLP64" (only long long and pointer are 64 bits; long and int are 32 bits).
* Use size_t for unsigned number of bytes variables, ptrdiff_t for signed pointer subtraction results. In particular, do not use uintN, which is just shorthand for unsigned int, and so may not be big enough.

= Header files =

== #ifndef wrappers ==

Use this exact form for #ifndef wrappers in header files:

#ifndef <guard>
#define <guard>
...
#endif // <guard>

GCC and clang recognize this idiom and avoid re-reading headers that use it. Don't put any code before the #ifndef or after the #endif, and don't put anything else in the #ifndef, otherwise the optimization will be thwarted and the file will be multiply-included. (Check with the -H option if you want to be sure.)

Include guards should be named by determining the fully-qualified include path,
then substituting _ for '/' and '.' and '-' in it. For example, js/src/vm/Stack-inl.h's guard is vm_Stack_inl_h_, and js/public/Vector.h's guard is js_Vector_h (because its include path is js/Vector.h).

== #include paths ==

All #include statements should use a fully-qualified (within SpiderMonkey) path, even if it's not necessary. For example, this:

#include "vm/Stack.h"

not:

#include "Stack.h"

This keeps things consistent and helps with the ordering.

For headers in js/public/, the prefix is "js/", e.g.:

#include "js/Vector.h"

For headers in mfbt/, the prefix is "mozilla/", e.g.:

#include "mozilla/Assertions.h"

== #include ordering ==

The following order is used for module X:
* If X-inl.h exists, it goes first. (And X-inl.h's first #include should be X.h.) Otherwise, X.h goes first. This rule ensures that X.h and X-inl.h both #include all the headers that they need themselves.
* mozilla/*.h
* <*.h>
* js*.h
* */*.h (this includes the public JSAPI headers in js/public/*.h which should be included using the form js/*.h)
* js*inlines.h
* */*-inl.h.

Keep (case-insensitive) lexicographic order with each section.

The presence of conditionally-compiled #include statements complicates thing. If you have a single #include statement within a #if/#ifdef/#ifndef block, placing the block in the appropriate section is straightforward. If you have multiple #include statements within a block, use your judgment as to where the best place for it is.

Example for X.cpp:

#include "X.h" // put "X-inl.h" instead, if it exists

#include "mozilla/HashFunctions.h"

#include <string.h>

#include "jsbar.h"
#ifdef BAZ
# include "jsbaz.h"
#endif
#include "jscaz.h"

#include "ds/Baz.h"
#include "js/Bar.h"
#include "vm/Bat.h"

#include "jssqueeinlines.h"
#include "jswoot-inl.h"

#include "frontend/Thingamabob-inl.h"
#include "vm/VirtualReality-inl.h"

= C++ =

== Namespaces ==

* Public functions and types should be in the JS:: namespace, in preference to the old JS/JS_ name prefixes.
* Library-private and friend functions should be in the js:: namespace, in preference to the old js_ name prefix.
* Compile-time-evaluated functions (i.e., template meta-functions) should be in 'js::tl::', the "template library" namespace, to avoid collision with their runtime counterparts.
* In SpiderMonkey .cpp files, it is okay to have 'using namespace js;', but it is not okay to do the same with any other namespace, like JS:: or mozilla::. These can introduce ambiguities that come and go depending on which .cpp files the build system decides to unify.
* If you do have names in JS:: that should be readily available throughout SpiderMonkey, you may add a 'using' declaration to js/src/NamespaceImports.h.
* Avoid unnamed namespaces unless they are necessary to give a class's members internal linkage. Although the C++ standard officially deprecates 'static' on functions, 'static' has the following advantages over unnamed namespaces:
** It is difficult to name functions in unnamed namespaces in gdb.
** Static says "this is a translation-unit-local helper function" on the function, without having to look around for an enclosing "namespace {".

== Enums ==

Older code uses SHOUT_REALLY_LOUD for enum values, newer code uses InterCaps. Enums should be preferred to boolean arguments for ease of understanding at the invocation site.

== Classical OOP ==

* Most structs can become classes, with associated functions becoming methods. This already started for the [https://bugzilla.mozilla.org/show_bug.cgi?id=upvar2 upvar2 bug].
** Style detailing: mrbkap suggests left brace before class body on its own line in column 1 to match function style and facilitate vim navigation. People do this already when inheriting, since the left brace can get lost in the superclass(es).
class JSObject
{
...
}
* Member variable names, private or public, are sometimes decorated with a trailing '_'.
class Fail
{
size_t capacity; // common
T *begin_; // also common, being used more as time goes on
}
Sometimes a canonical argument name may conflict with a member name. In this case, one can disambiguate with "this->", although such explicit qualification should only be added when necessary:
class C
{
size_t count;
bool fresh;
void change(size_t count) {
this->count = count;
this->fresh = false; // verbose and unnecessary
}
};
* Most macros become inline helpers. With LiveConnect gone on mozilla-central, we can make the helpers methods of relevant structs or classes finally, instead of static inline functions.
* Based on 20+ years of bad experiences, we are going to go slow and resist virtual methods and bases, MI, and the like. Function pointer tables for now, as before -- see [https://bugzilla.mozilla.org/show_bug.cgi?id=408416 JSObjectOps needs a make-over].
* Templates are good, Mozilla has positive experience and the portability is there for the kind of [http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization RAII] helpers we need.
* No exceptions, so std is hard to use. There is initial work underway to make STL-like containers that mesh well with the rest of the JS engine (see js::Vector, js::HashMap, js::Pool).
** There are still improvements to be made to the new hash table: double-hash implementation; improve bit-mixing into multiplicative hash if the cycle costs can be supported (measurement is required and we should understand down to the bits what is going on); a js::HashSet or js::HashMap<T,void> specialization such that set-like use of hashtables do not waste any space on values.

=== Initializer lists ===

Initializer lists can break in one of two ways. The first may be preferable when constructors take few arguments:

class Ninja : public WeaponWeilder, public Camouflagible,
public Assassinatable, public ShapeShiftable
{
Ninja() : WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

The other permitted style mitigates longer-identifiers-squishing-text-against-the-right-side-of-the-screen-syndrome by using a half-indented colon:

class Ninja
: public WeaponWeilder, public Camouflagible, public Assassinatable,
public ShapeShiftable
{
Ninja()
: WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

=== Inline methods ===

If the method in question fits on one line and is branch free, do a one liner:

class Eater
{
void eat(Eaten &other) { other.setConsumed(); }
};

If it's too long, put the type, declarator including formals (unless they overflow), and left brace all on the first line:

class Eater
{
Food *obtainFoodFromEatery(Eatery &eatery) {
if (!eatery.hasFood())
return NULL;
return eatery.purchaseFood();
}
};

For out-of-line inlines (when the definitions are too unwieldy to place in the class definition) use the inline keyword as an indicator that there's an out-of-line inline definition:

class SpaceGoo
{
inline BlobbyWrapper *enblob(Entity &other);
};

inline BlobbyWrapper *
SpaceGoo::enblob(Entity &other)
{
/* ... */
}

== References ==

* [https://developer.mozilla.org/en/Mozilla_Coding_Style_Guide Mozilla's coding style guide].
* [http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml Google's C++ coding style guide].

= Exceptions to this coding style =

SpiderMonkey contains some code imported from other projects, e.g. ctypes/libffi/, that is minimally modified. Such code does not have to follow SpiderMonkey style.

Electrolysis

2014-09-26T14:46:35Z

Jorend: /* Known Issues */

==Goal==

The goal of the Electrolysis project ("e10s" for short) is to run web content in a separate process from Firefox itself. The two major advantages of this model are security and performance. Security would improve because the content processes could be sandboxed (although sandboxing the content processes is a separate project from Electrolysis). Performance would improve because the browser UI would not be affected by poor performance of content code (be it layout or JavaScript). Also, content processes could be isolated from each other, which would have similar security and performance benefits.

Although the Gecko platform supports multiple processes, the Firefox frontend is not designed to use them. Work to make the frontend (including addons) support multiple processes was begun in early 2013. The [[Electrolysis/Roadmap|project roadmap]] has more details.

==Enabling and Disabling Electrolysis==

To enable or disable e10s, open Nightly's Preferences and check the "Enable E10S" checkbox. You will need to restart Nightly. Alternately, you can also toggle the ''browser.tabs.remote'' and ''browser.tabs.remote.autostart'' prefs to enable (true) or disable (false) e10s.

==Contributing==

The simplest way to help out is to file bugs when you find them.

* Link to all open e10s bugs: http://is.gd/QripTz
** Please check the open bugs for duplicates before filing a new bug.
* Link to file new e10s bug: http://is.gd/aTza8A
** Please add the tracking-e10s:? flag so we can more easily track your bug.

Most bugs in e10s occur because code in the chrome process tries to access data in a content process. All of the DOM objects for a XUL browser element, as well as its DocShell, live in the content process. Typical access paths are via <code>browser.contentWindow</code>, <code>browser.docShell</code>, or some variation of them. Often, these property accesses will generate errors in the console, which makes these bugs fairly easy to detect. MDN has a good introduction to e10s, useful for both Firefox and add-on developers: https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox

==What to Expect==

Basic browsing should work as expected. Tabs that are loaded remotely (i.e., in a separate process) will have their title underlined. By default, only one content process is used. You can control this with the dom.ipc.processCount preference.

===Known Issues===
Known issues you might run into when testing e10s:
* HTTP redirects don't always work: {{bug|997808}}, {{bug|1050869}}
* Printing does not work: {{bug|927188}}
* Site logins fail if third-party cookies are always blocked: {{bug|1049299}}
* Accessibility disables e10s: {{bug|1029143}}
* Personal spellcheck dictionaries don't work: {{bug|1030449}}
* Middle-click, Open Link in New ... options doesn't work {{bug|1066924}}
* Spellcheck suggestions hang around in the right-click menu forever {{bug|1073527}}

===Add-ons Compatibility===

A list of tested add-ons (compatible and incompatible) is available at http://arewee10syet.com. Some popular add-ons that are currently broken with e10s:

* Bugzilla Tweaks/BugzillaJS: {{bug|972507}}
* HTTPS Everywhere: {{bug|1014986}}
* Tree Style Tabs: {{bug|1042680}}
* 1Password: {{bug|1042195}}
* NoScript: {{bug|1058542}}

==Communication==

{| class="wikitable fullwidth-table"
| Weekly Team Meeting
|| [http://arewemeetingyet.com/Los%20Angeles/2014-04-24/14:30/w/E10s%20Weekly%20Team%20Meeting Thursday at 2:00pm PT] for 30 mins
* Vidyo: [https://v.mozilla.com/flex.html?roomdirect.html&key=njJM9NHQBt2a "e10s"]
* Invitation: Contact billm@mozilla.com to get added to the meeting invite list.
* Dial In Information:
* [https://etherpad.mozilla.org/E10s-meeting-notes Meeting Notes Etherpad]
* Historical Notes: [[Content Processes/Meetings|Meeting Agendas and Notes]]
|-
| IRC
||
* Server: irc.mozilla.org
* Channel: [irc://irc.mozilla.org/e10s #e10s]
|-
| Tracking bugs
||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=fxe10s fxe10s] for frontend bugs
* [https://bugzilla.mozilla.org/show_bug.cgi?id=core-e10s core-e10s] for platform bugs
* [https://bugzilla.mozilla.org/show_bug.cgi?id=e10s-addons e10s-addons] for add-on compatibility
|-
| Newsgroup/Mailing List
||
* https://lists.mozilla.org/listinfo/dev-tech-electrolysis
|-
| Project branch
||
* We use the project branch only for experimental code. We don't recommend people test with it. Please use mozilla-central instead.
* https://hg.mozilla.org/projects/larch/
* https://github.com/mozilla/mozilla-central/tree/larch
|}

==People==
{| class="wikitable fullwidth-table"
| Project Champion
||
* Andreas Gal ( A )
|-
| High Level Oversight
||
* Johnathan Nightingale ( I )
* Gavin Sharp ( A )
|-
| Engineering Management
||
* Brad Lassey ( R )
|-
| Project Management
||
* Chris Peterson ( R )
|-
| QA
||
* Juan Becerra (QA lead)
|-
| Development Team
||
* Nicholas Alexander ( R )
* Mike Conley ( R )
* Felipe Gomes (Firefox front-end) ( R )
* Blake Kaplan ( R )
* William McCloskey ( R )
* Jim Mathies ( R )
* Allison Naaktgeboren ( R )
* John Schoenick (plugins) ( R )
* Tom Schuster ( R )
* Tomislav Jovanovic (addon-sdk) ( R )
|-
| Other Teams
|
* Accessibility: Alexander Surkov and Trevor Saunders ([https://bugzilla.mozilla.org/show_bug.cgi?id=646596 bug 646596])
* Addon Developer Relations: Jorge Villalobos
* Developer Tools: Rob Campbell ([https://bugzilla.mozilla.org/show_bug.cgi?id=875871 bug 875871])
* IME: Makoto Kato (alternately, Masayuki Nakano) ([https://bugzilla.mozilla.org/show_bug.cgi?id=926798 bug 926798])
* Jetpack: Dave Townsend
* OMTC/Windows: Nick Cameron ([https://bugzilla.mozilla.org/show_bug.cgi?id=756608 bug 756608])
* Printing: bz ([https://bugzilla.mozilla.org/show_bug.cgi?id=927188 bug 927188])
* Plugins: Josh Aas (OS X), Karl Tomlinson (Linux)
* Sandboxing: Brian Bondy, Sid Stamm ([https://bugzilla.mozilla.org/show_bug.cgi?id=925570 bug 925570])
* WebAudio: Ehsan Akhgari (WebAudio works fine in e10s.)
* WebRTC: Randell Jesup or Eric Rescorla. WebRtc is currently getting ready to go into B2G - mozGetUserMedia will be in 26/1.2, and PeerConnections will be in 28/1.3.
* e10s tests: Mark Hammond
|}

Here is what the letters following each name stand for, those higher on the list include all those below:

* R = Responsible for deliverable, in most cases this is anyone writing code.
* A = Accountable for the final decision making on some aspect of the project, often leadership that is not working on code but have go, no go decision making.
* C = Needs to be consulted on key topics, often this would be for subject mater experts that need to be consulted but don't have decision making power.
* I = Needs to be kept informed, those that just need regular status reports sent to them.

==Reference==

* [https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox MDN: Working with multiprocess Firefox]
* [https://developer.mozilla.org/en-US/docs/The_message_manager The message manager]
* [https://developer.mozilla.org/en-US/docs/Cross_Process_Object_Wrappers Cross-process object wrappers]
* [[Electrolysis/Archive | Archive of past content on this page]]
* [https://etherpad.mozilla.org/uYS8ZplOMU Electrolysis platform notes]
* [https://etherpad.mozilla.org/rRk4aEHkwC Notes on the Chromium IPC library]
* [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AhFRRYurPzRndHQwUVNscThIbFBsYmNRaU44LVlDdlE#gid=0 Addon Compatibility Test Results]
* [http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIMessageManager.idl#13 IDL comments about Message Manager]
* Tim Taubert's [http://timtaubert.de/blog/2011/08/firefox-electrolysis-101/ "Firefox Electrolysis 101"] blog post (2011)

== Meeting Notes ==

; For latest meeting notes, see the [https://e10s.etherpad.mozilla.org/meeting-notes Meeting Notes Etherpad].

Create a new weekly agenda from the [[Electrolysis/Meetings/0-0-0|template]]:
<createbox>
align=left
type=create
preload=Electrolysis/Meetings/0-0-0
default={{#time: Y-m-d | thursday}}
prefix=Electrolysis/Meetings/
</createbox>

{| class="toccolours" style="width: 100%"
|{{Special:PrefixIndex/Electrolysis/Meetings/}}
|}

JavaScript:SpiderMonkey:Coding Style

2014-09-16T18:52:54Z

Jorend:

= Functions =

* Public function names begin with JS_ followed by capitalized "intercaps", e.g. JS_NewObject.
* Extern but library-private function names use a js_ prefix and mixed case, e.g. js_SearchScope.
* Most static function names have unprefixed, mixed-case names: GetChar.
* But static native methods of JS objects have lowercase, underscore-separated or intercaps names, e.g., str_indexOf.
* Function return types are on a separate line preceding the function name.
* Function braces go on the line following the function name.
void DoThis() /* bad */
{
...
}
void
DoThis() /* OK */
{
...
}

= Other Symbols =

* Library-private and static data use underscores, not intercaps (but library-private data do use a js_ prefix).
* Scalar type names are lowercase and js-prefixed: jsdouble.
* Aggregate type names are JS-prefixed and mixed-case: JSObject.
* Macros are generally ALL_CAPS and underscored, to call out potential side effects, multiple uses of a formal argument, etc. Line continuation characters should all line up, in column 79 if that exceeds the width of all the macro text. Macro parameters should be of the form name_ (instead of something like __name).

= Indentation =

* Use spaces, not tabs. There should be no tabs in source files.
* Four spaces of indentation per statement nesting level.
* "<code>case L:</code>" labels in <code>switch</code> statements count as half of a nesting level, so indent two spaces, with the labeled statements indenting two more for a standard four spaces indentation from <code>switch</code> to a case-controlled statement.
switch (discriminant) {
case L1:
DoSomething();
. . .
}
* Function arguments that overflow the first line of the call expression should be aligned to underhang the first argument (to start in overflow lines in the column after the opening parenthesis).
JS_SetContext(rt, /* bad */
cx);
JS_SetContext(rt, /* OK */
cx);

= Whitespace in declarations =

These rules are inconsistently applied. Be consistent with the code you're editing rather than adhere too closely to these guidelines!

* In a declaration of a pointer, the <code>*</code> goes with the variable name:
char* s; /* bad */
char *s; /* OK */
* Even in the return type of a method:
class JSString
{
...
JSString* dependentBase() const; /* bad */
JSString * dependentBase() const; /* bad */
JSString *dependentBase() const; /* OK */
...
};
* But in top-level function declarations/definitions, put a line break immediately before the name being declared:
extern const char *
js_GetStringBytes(JSContext *cx, JSString *str); /* OK */
* And put a space in <code>*JS_FASTCALL</code>, because that would be crazy.
extern JSString *JS_FASTCALL /* bad */
js_ConcatStrings(JSContext *cx, JSString *left, JSString *right);
extern JSString * JS_FASTCALL /* OK */
js_ConcatStrings(JSContext *cx, JSString *left, JSString *right);
* In C++ method declarations with default arguments, use spaces and comments like so:
static void
Frob(JSContext *cx, uint32_t defaultValue = 0);
static void
Frob(JSContext *cx, uint32_t defaultValue /* = 0 */)
{
/* ... */
}

= Other whitespace =

* Code should fit within 99 columns; comments should fit within 80 columns; both figures include indentation. Break down lines that are too long by splitting after a binary operator.
* Exception: in a <code>switch</code> statement where each case is a trivially-short statement, it's ok to put the <code>case</code>, the statement, and the <code>break;</code> all on one line.
* Comment <code>/* FALL THROUGH */</code> in place of missing <code>break</code> when intentionally falling through from one case-controlled statement sequence into another, or into the <code>default</code> statements.
* Do not use spaces between a function name and its arguments list, or between an array name and the square bracket. Also, do no use spaces after a bracket. Use a space after a comma to separate arguments.
JS_SetContext ( rt, cx ); /* bad */
JS_SetContext(rt, cx); /* OK */
* Use a space between a C keyword and parentheses.
if(condition) /* bad */
if (condition) /* OK */
* In a conditional, if the consequent (and, if present, the alternate) is a single statement, no braces are used.
if (today == "Tuesday")
puts("I don't have my wallet on me.");
else
puts("I would gladly pay you on Tuesday for a hamburger today.");
However, if ''either'' the consequent or alternate is a block of multiple statements, braces are used on both.
if (canSwingFromWeb) {
p->swingFromWeb();
} else {
JS_ASSERT(p->isSpiderPig());
p->doWhateverSpiderPigDoes();
}
* Conditions with multi-line tests should put the brace on the new line to provide a visual separation between the condition and the body.

types::TypeSet *types = frame.extra(lhs).types;
if (JSOp(*PC) == JSOP_SETPROP && id == types::MakeTypeId(cx, id) &&
types && !types->unknownObject() &&
types->getObjectCount() == 1 &&
types->getTypeObject(0) != NULL &&
!types->getTypeObject(0)->unknownProperties())
{
JS_ASSERT(usePropCache);
types::TypeObject *object = types->getTypeObject(0);
types::TypeSet *propertyTypes = object->getProperty(cx, id, false);
...
} else {
...
}
However, if there is already a visual separation between the condition and the body, putting the { on a new line isn't necessary:

if (forHead->pn_kid1 && NewSrcNote2(cx, cg, SRC_DECL,
(forHead->pn_kid1->isOp(JSOP_DEFVAR))
? SRC_DECL_VAR
: SRC_DECL_LET) < 0) {
return false;
}
* <code>for</code> loop heads go on one line where possible; when not possible, initializer part, update, and termination parts each go on separate lines
for (int i = 0;
i < 5;
i++) { /* bad, could all fit on one line */
doStuff();
}
for (int i = 0; i < 5; i++) /* OK */
doStuff();
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS; ind++) { /* bad */
obj->setSlot(ind, DoubleValue(utcTime));
}
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS;
ind++) { /* OK */
obj->setSlot(ind, DoubleValue(utcTime));
}
* In comments, use one space, not two, between sentences and after a colon.

= Control Flow =

* Minimize indentation using return, break, and continue where appropriate. Prefer return (break, continue) statements to cast out abnormal cases, instead of nesting "if/else" statements and indenting the common cases.
void
MyFunction(int n)
{
if (n) { /* bad */
...
}
}
void
MyFunction(int n)
{
if (!n)
return; /* OK */
...
}

* If an "if" statement controls a "then" clause ending in a return statement, do not use "else" after return.
if (condition) { /* bad */
DoThis();
return;
} else {
DoThat();
}

if (condition) { /* OK */
DoThis();
return;
}
DoThat();

* Avoid similar arbitrary patterns and non-sequiturs:
if (condition) { /* bad */
DoThis();
DoThat();
} else {
CleanUp();
return;
}
DoTheOther();
if (!condition) { /* OK */
CleanUp();
return;
}
DoThis();
DoThat();
DoTheOther();

= Comments =

* In C files, always use C style comments. C++ comments are ok otherwise.
* Terminate a comment with a period (so try to make comments be complete sentences).
/* This is a good comment. */
// This is also a good comment.
* For C-style multiline comments, align with any indentation, and start every line with an asterisk. Asterisks stack in the same column. Precede the multiline comment with one empty line unless the prior line ends in a left brace. The first line of the comment contains only leading space followed by <code>/*</code>. Multiline comments should also be bracketed.
<pre>
if (condition) {
/*
* This is a lengthy C-style
* multiline comment.
*/
// This is a length
// C++-style comment
DoYourStuff();
}
</pre>

= Entry Points and Callbacks =

* DLL entry points have their return type expanded within a JS_PUBLIC_API() macro call, to get the right Windows secret type qualifiers in the right places for all build variants.
* Callback functions that might be called from a DLL are similarly macroized with JS_STATIC_DLL_CALLBACK (if the function otherwise would be static to hide its name) or JS_DLL_CALLBACK (this macro takes no type argument; it should be used after the return type and before the function name).

= Data Types and Alignments =

* As with all Mozilla code, SpiderMonkey needs to compile and execute correctly on many platforms, including 64-bits systems.
* JS and NSPR have common roots in the dawn of time (Netscape 2), and the <code>JS_THREADSAFE</code> mode of building SpiderMonkey depends on NSPR, so reading the [http://www.mozilla.org/projects/nspr/reference/html/ NSPR documentation] is well worth your while.
* Not all 64-bit systems use the same integer type model: some are "LP64" (long and pointer are 64 bits, int is 32 bits), while others are "LLP64" (only long long and pointer are 64 bits; long and int are 32 bits).
* Use size_t for unsigned number of bytes variables, ptrdiff_t for signed pointer subtraction results. In particular, do not use uintN, which is just shorthand for unsigned int, and so may not be big enough.

= Header files =

== #ifndef wrappers ==

Use this exact form for #ifndef wrappers in header files:

#ifndef <guard>
#define <guard>
...
#endif // <guard>

GCC and clang recognize this idiom and avoid re-reading headers that use it. Don't put any code before the #ifndef or after the #endif, and don't put anything else in the #ifndef, otherwise the optimization will be thwarted and the file will be multiply-included. (Check with the -H option if you want to be sure.)

Include guards should be named by determining the fully-qualified include path,
then substituting _ for '/' and '.' and '-' in it. For example, js/src/vm/Stack-inl.h's guard is vm_Stack_inl_h_, and js/public/Vector.h's guard is js_Vector_h (because its include path is js/Vector.h).

== #include paths ==

All #include statements should use a fully-qualified (within SpiderMonkey) path, even if it's not necessary. For example, this:

#include "vm/Stack.h"

not:

#include "Stack.h"

This keeps things consistent and helps with the ordering.

For headers in js/public/, the prefix is "js/", e.g.:

#include "js/Vector.h"

For headers in mfbt/, the prefix is "mozilla/", e.g.:

#include "mozilla/Assertions.h"

== #include ordering ==

The following order is used for module X:
* If X-inl.h exists, it goes first. (And X-inl.h's first #include should be X.h.) Otherwise, X.h goes first. This rule ensures that X.h and X-inl.h both #include all the headers that they need themselves.
* mozilla/*.h
* <*.h>
* js*.h
* */*.h (this includes the public JSAPI headers in js/public/*.h which should be included using the form js/*.h)
* js*inlines.h
* */*-inl.h.

Keep (case-insensitive) lexicographic order with each section.

The presence of conditionally-compiled #include statements complicates thing. If you have a single #include statement within a #if/#ifdef/#ifndef block, placing the block in the appropriate section is straightforward. If you have multiple #include statements within a block, use your judgment as to where the best place for it is.

Example for X.cpp:

#include "X.h" // put "X-inl.h" instead, if it exists

#include "mozilla/HashFunctions.h"

#include <string.h>

#include "jsbar.h"
#ifdef BAZ
# include "jsbaz.h"
#endif
#include "jscaz.h"

#include "ds/Baz.h"
#include "js/Bar.h"
#include "vm/Bat.h"

#include "jssqueeinlines.h"
#include "jswoot-inl.h"

#include "frontend/Thingamabob-inl.h"
#include "vm/VirtualReality-inl.h"

= C++ =

== Namespaces ==

* Public functions and types should be in the JS:: namespace, in preference to the old JS/JS_ name prefixes.
* Library-private and friend functions should be in the js:: namespace, in preference to the old js_ name prefix.
* Compile-time-evaluated functions (i.e., template meta-functions) should be in 'js::tl::', the "template library" namespace, to avoid collision with their runtime counterparts.
* In SpiderMonkey .cpp files, it is okay to have 'using namespace js;', but it is not okay to do the same with any other namespace, like JS:: or mozilla::. These can introduce ambiguities that come and go depending on which .cpp files the build system decides to unify.
* If you do have names in JS:: that should be readily available throughout SpiderMonkey, you may add a 'using' declaration to js/src/NamespaceImports.h.
* Avoid unnamed namespaces unless they are necessary to give a class's members internal linkage. Although the C++ standard officially deprecates 'static' on functions, 'static' has the following advantages over unnamed namespaces:
** It is difficult to name functions in unnamed namespaces in gdb.
** Static says "this is a translation-unit-local helper function" on the function, without having to look around for an enclosing "namespace {".

== Enums ==

Older code uses SHOUT_REALLY_LOUD for enum values, newer code uses InterCaps. Enums should be preferred to boolean arguments for ease of understanding at the invocation site.

== Classical OOP ==

* Most structs can become classes, with associated functions becoming methods. This already started for the [https://bugzilla.mozilla.org/show_bug.cgi?id=upvar2 upvar2 bug].
** Style detailing: mrbkap suggests left brace before class body on its own line in column 1 to match function style and facilitate vim navigation. People do this already when inheriting, since the left brace can get lost in the superclass(es).
class JSObject
{
...
}
* Member variable names, private or public, are sometimes decorated with a trailing '_'.
class Fail
{
size_t capacity; // common
T *begin_; // also common, being used more as time goes on
}
Sometimes a canonical argument name may conflict with a member name. In this case, one can disambiguate with "this->", although such explicit qualification should only be added when necessary:
class C
{
size_t count;
bool fresh;
void change(size_t count) {
this->count = count;
this->fresh = false; // verbose and unnecessary
}
};
* Most macros become inline helpers. With LiveConnect gone on mozilla-central, we can make the helpers methods of relevant structs or classes finally, instead of static inline functions.
* Based on 20+ years of bad experiences, we are going to go slow and resist virtual methods and bases, MI, and the like. Function pointer tables for now, as before -- see [https://bugzilla.mozilla.org/show_bug.cgi?id=408416 JSObjectOps needs a make-over].
* Templates are good, Mozilla has positive experience and the portability is there for the kind of [http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization RAII] helpers we need.
* No exceptions, so std is hard to use. There is initial work underway to make STL-like containers that mesh well with the rest of the JS engine (see js::Vector, js::HashMap, js::Pool).
** There are still improvements to be made to the new hash table: double-hash implementation; improve bit-mixing into multiplicative hash if the cycle costs can be supported (measurement is required and we should understand down to the bits what is going on); a js::HashSet or js::HashMap<T,void> specialization such that set-like use of hashtables do not waste any space on values.

=== Initializer lists ===

Initializer lists can break in one of two ways. The first may be preferable when constructors take few arguments:

class Ninja : public WeaponWeilder, public Camouflagible,
public Assassinatable, public ShapeShiftable
{
Ninja() : WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

The other permitted style mitigates longer-identifiers-squishing-text-against-the-right-side-of-the-screen-syndrome by using a half-indented colon:

class Ninja
: public WeaponWeilder, public Camouflagible, public Assassinatable,
public ShapeShiftable
{
Ninja()
: WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

=== Inline methods ===

If the method in question fits on one line and is branch free, do a one liner:

class Eater
{
void eat(Eaten &other) { other.setConsumed(); }
};

If it's too long, put the type, declarator including formals (unless they overflow), and left brace all on the first line:

class Eater
{
Food *obtainFoodFromEatery(Eatery &eatery) {
if (!eatery.hasFood())
return NULL;
return eatery.purchaseFood();
}
};

For out-of-line inlines (when the definitions are too unwieldy to place in the class definition) use the inline keyword as an indicator that there's an out-of-line inline definition:

class SpaceGoo
{
inline BlobbyWrapper *enblob(Entity &other);
};

inline BlobbyWrapper *
SpaceGoo::enblob(Entity &other)
{
/* ... */
}

== References ==

* [https://developer.mozilla.org/en/Mozilla_Coding_Style_Guide Mozilla's coding style guide].
* [http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml Google's C++ coding style guide].

= Exceptions to this coding style =

SpiderMonkey contains some code imported from other projects, e.g. ctypes/libffi/, that is minimally modified. Such code does not have to follow SpiderMonkey style.

WeeklyUpdates/2013-07-01

2013-07-01T15:32:41Z

Jorend:

[[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} -1 week}}|« previous week]] | [[WeeklyUpdates|index]] | [[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} +1 week}}|next week »]]

{{conf|8600}}

__TOC__

= All-hands Status Meeting Agenda =

Items in this section will be shared during the live all-hand status meeting.

== Friends of the Tree [[Image:Tree.gif|Friends of the Tree]] ==
* Casey Ransom of Mozilla IT for a breakthrough find that led to relieving bugzilla slowness for all.
* Jeff Walden of the JavaScript team for an epic review marathon. Jeff performed speedy yet vigilant reviews on dozens of cleanup patches in the JavaScript front end.

== Upcoming Events ==

=== This Week ===

=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===

=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===
Learn how Firefox OS aims to level the mobile playing field, along with market insights and some tips on how to talk about Firefox OS from a consumer angle.
* Location: Live Remote on Air Mozilla (https://air.mozilla.org)
* Start time: 02 July 2013 - 15:00 UTC (8:00am PDT)
* Speakers: David Slater, Margaret Schroeder, Chad Weiner, Grace Jimenez

=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===

=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===

=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===

=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===

=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===

=== Next Week ===

== Product Status Updates (voice updates) ==

=== Firefox Desktop ===
''Speaker Location:''

=== Firefox Mobile ===
''Speaker Location:''

=== Thunderbird ===
''Speaker Location:''

=== Older Branch Work ===
''Speaker Location:''

=== Webmaker ===
''Speaker Location:'' Ankit Gadgil, Inda

[[File:Maker Party events.png|500px]]

* What's going on with [http://webmaker.org/party Maker Party]?
* Why it's exciting and how you can get involved.
** [https://webmaker.org/events Find an event near you.]
** [https://webmaker.org/events Host your own.] Our event guides make it easy!

=== Identity ===
''Speaker Location:''

=== Services ===
''Speaker Location:''

=== Firefox OS ===
''Speaker Location:''

=== Grow Mozilla ===
''Speaker Location: San Francisco''

Help us [https://blog.mozilla.org/community/2013/04/15/help-us-build-a-history-of-mozilla-told-by-mozillians/ build a history of Mozilla told by Mozillians]. Please share your memories about this Mozilla milestone:

* February 13, 2007: [https://blog.mozilla.org/community/2013/07/01/milestone-the-first-draft-of-the-mozilla-manifesto-is-posted/ The first draft of the Mozilla Manifesto is posted]

[[File:2007_manifesto.jpg|250px]]

== Speakers ==

The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week.

{| class="fullwidth-table"
|-
! Presenter
! Title
! Topic
! Location
! Share?
! Media
! More Details
|-
| Who Are You?
| What Do You Do?
| What are you going to talk about?
| Where are you presenting from? (Moz Space, your house, space)
| Will you be sharing your screen? (yes/no, other info)
| Links to slides or images you want displayed on screen
| Link to where audience can find out more information
|-
| Kate Naszradi, Mardi Douglass, Dino Anderson, Melek Jebnoun
|
| Summit Planning Assembly feedback
| Kate = remote, Mardi/Dino = SF, Melek = remote (Tunisia)
| Yes, Kate has slides (she's presenting first)
|
| Link to Melek's blog post (French): http://jebmelek.wordpress.com/2013/06/30/retour-sur-le-weekend-du-mozilla-summit-assembly/ , link to Summit updates : https://blog.mozilla.org/community/category/summit/
-
|-
| Kaitlin Thaney
| Director, Mozilla Science Lab
| The new Science Lab, who we are, what we hope to achieve
| Brooklyn, NY
| No
| N/A
| [http://wiki.mozilla.org/ScienceLab wiki.mozilla.org/ScienceLab] ; [http://twitter.com/MozillaScience @MozillaScience]
|}

= Roundtable =

Do you have a question about a Mozilla Project or initiative? Let us know by Friday- we'll do our best to get you an answer.

Please note that we may not always be able to get to every item on this list, but we will try!

{| class="fullwidth-table"
|-
! Who are you?
! Area of question
! Question
|-
| ''What's your name? What do you work on?''
| ''Is your question about policy, a product, a Foundation initiative, etc.''
| ''What would you like to know?''

|-
|}

= Welcome! =

Let's say hello to some new Mozillians!

== Introducing New Hires ==
{| class="fullwidth-table"
|-
! New Hire
! Introduced by
! Speaker location
! New Hire location
! Will be working on
|-
| ''Who is the new hire?''
| ''Who will be introducing that person?''
| ''Where is the introducer?''
| ''Where will the new person be working from?''
| ''What will the new person be working on?''
|-
| Michael Comella
| Mark Finkle
| Remote - PA
| SF
| Mobile
|-
| Keegan McAllister
| Azita Rashed
| MTV
| SFO
| Engineering
|-
| Christoph Kerschbaumer
| Sid Stamm
| MTV
| Remote - CA
| Engineering - Security & Privacy
|-
| Alexander Surkov
| David Bolter
| Toronto
| Toronto
| Engineering
|}

== Introducing New Interns ==
{| class="fullwidth-table"
|-
! New Intern
! Introduced by
! Speaker location
! New Hire location
! Will be working on
|-
| Anthony Verez
| Joe Stevensen
| MV
| MV
| Ops Security
|}

= <meta> =

Notes and non-voice status updates that aren't part of the live meeting go here.

== Status Updates By Team (*non-voice* updates) ==

=== Firefox ===

=== Platform ===

=== Services ===

=== Messaging ===

=== Mobile ===

=== IT ===

=== Release Engineering ===

=== QA ===

==== Test Execution ====

==== WebQA ====

==== QA Community ====

=== Automation & Tools ===

=== Security ===

=== Engagement ===

==== PR ====

==== Events ====

[[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} -1 week}}|« previous week]] | [[WeeklyUpdates|index]] | [[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} +1 week}}|next week »]]

{{conf|8600}}

__TOC__

= All-hands Status Meeting Agenda =

Items in this section will be shared during the live all-hand status meeting.

== Friends of the Tree [[Image:Tree.gif|Friends of the Tree]] ==

== Upcoming Events ==

=== This Week ===

=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===

=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===

=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===

=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===

=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===

=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===

=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===

=== Next Week ===

== Product Status Updates (voice updates) ==

=== Firefox Desktop ===
''Speaker Location:''

=== Firefox Mobile ===
''Speaker Location:''

=== Thunderbird ===
''Speaker Location:''

=== Older Branch Work ===
''Speaker Location:''

=== Webmaker ===
''Speaker Location:''

=== Identity ===
''Speaker Location:''

=== Services ===
''Speaker Location:''

=== Firefox OS ===
''Speaker Location:''

=== Grow Mozilla ===
''Speaker Location:''

== Speakers ==

The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week.

{| class="fullwidth-table"
|-
! Presenter
! Title
! Topic
! Location
! Share?
! Media
! More Details
|-
| Who Are You?
| What Do You Do?
| What are you going to talk about?
| Where are you presenting from? (Moz Space, your house, space)
| Will you be sharing your screen? (yes/no, other info)
| Links to slides or images you want displayed on screen
| Link to where audience can find out more information
|-
|}

= Roundtable =

Do you have a question about a Mozilla Project or initiative? Let us know by Friday- we'll do our best to get you an answer.

Please note that we may not always be able to get to every item on this list, but we will try!

{| class="fullwidth-table"
|-
! Who are you?
! Area of question
! Question
|-
| ''What's your name? What do you work on?''
| ''Is your question about policy, a product, a Foundation initiative, etc.''
| ''What would you like to know?''

|-
|}

= Welcome! =

Let's say hello to some new Mozillians!

== Introducing New Hires ==
{| class="fullwidth-table"
|-
! New Hire
! Introduced by
! Speaker location
! New Hire location
! Will be working on
|-
| ''Who is the new hire?''
| ''Who will be introducing that person?''
| ''Where is the introducer?''
| ''Where will the new person be working from?''
| ''What will the new person be working on?''
|-

|-
|}

== Introducing New Interns ==
{| class="fullwidth-table"
|-
! New Intern
! Introduced by
! Speaker location
! New Hire location
! Will be working on
|-
| ''Who is the new intern?''
| ''Who will be introducing that person?''
| ''Where is the introducer?''
| ''Where will the new person be working from?''
| ''What will the new person be working on?''
|-

|-
|}

= <meta> =

Notes and non-voice status updates that aren't part of the live meeting go here.

== Status Updates By Team (*non-voice* updates) ==

=== Firefox ===

=== Platform ===

=== Services ===

=== Messaging ===

=== Mobile ===

=== IT ===

=== Release Engineering ===

=== QA ===

==== Test Execution ====

==== WebQA ====

==== QA Community ====

=== Automation & Tools ===

=== Security ===

=== Engagement ===

==== PR ====

==== Events ====

==== Creative Team ====

==== Community Marketing ====

=== Support ===

=== Metrics ===

=== Evangelism ===

=== Labs ===

=== Apps ===

=== Developer Tools ===

=== Add-ons ===

=== Webdev ===

=== L10n ===

=== People Team ===

=== WebFWD ===

== Foundation Updates ==

==== Creative Team ====

==== Community Marketing ====

=== Support ===

=== Metrics ===

=== Evangelism ===

=== Labs ===

=== Apps ===

=== Developer Tools ===

=== Add-ons ===

=== Webdev ===

=== L10n ===

=== People Team ===

=== WebFWD ===

== Foundation Updates ==

Gaia/Hacking

2013-03-27T16:27:06Z

Jorend:

'''Note:''' This page is soon migrating to [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Gaia/Hacking MDN]. Please contribute your changes there.

Gaia is the collection of [https://developer.mozilla.org/apps web apps] which make up the front end of [http://www.mozilla.org/firefoxos/ Firefox OS] (codenamed [https://wiki.mozilla.org/B2G Boot to Gecko]).

Everything you see on the screen in Firefox OS is built using open web technologies, including the homescreen and dialer.

You can get started hacking on Gaia with nothing more than a web browser and a text editor, so what are you waiting for?

== Running Gaia Apps ==

There are two ways to run Gaia apps:

* B2G Desktop
* B2G on a device

=== B2G Desktop ===

B2G Desktop is a desktop build of the B2G app runtime used on devices where all apps should run as they would on a device, including the homescreen.

=== Aurora Builds (v1 everyone should use this) ===

You can download an Aurora build of B2G Desktop from [http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-b2g18/ http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-b2g18/] for Linux, OS X and Windows.

Aurora/Nightly builds include gaia by default, and they should just run out of the box. This is done by using a wrapper program. When a profile is bundled with the nightly build (GAIADIR specified in the mozconfig), the binary 'b2g' is a wrapper program and 'b2g-bin' is the actual b2g binary.

If you want to modify Gaia, you will need to separately clone and "build" Gaia:

$ git clone git://github.com/mozilla-b2g/gaia.git gaia
$ cd gaia
$ DEBUG=1 make

Then you just run with B2G Desktop instead of Firefox. The nightlies produced for TBPL use 'b2g-bin'. If you build a desktop build yourself without specifying "GAIADIR=/path/to/gaia/repo" in your mozconfig, use 'b2g':

$ /path/to/b2g-bin -profile /path/to/gaia/profile

On OSX, the b2g-bin will be in the B2G.app package contents, so the path is a little different:

$ /path/to/b2g/B2G.app/Contents/MacOS/b2g-bin -profile /path/to/gaia/profile

To update gaia you run the following command inside the Gaia directory:

$ git pull

(or "git fetch && git merge upstream/master" if you checked out from your own clone).

=== Gaia Version 2 ===

Use the below builds for work on version 2 of Gaia.

You can download a nightly build of B2G Desktop from [http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/ http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/] for Linux, OS X and Windows.

=== Build Your Own B2G Desktop ===

If you prefer you can build B2G Desktop yourself by checking it out from mozilla-central using Mercurial:

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

Before building, make sure you have the correct [https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions#Build_prerequisites build prerequisites] to build mozilla-central for your platform. After that, create a file called .mozconfig in your source tree to configure some options. Here's an example:

mk_add_options MOZ_OBJDIR=../build
mk_add_options MOZ_MAKE_FLAGS="-j9 -s"

ac_add_options --enable-application=b2g
ac_add_options --disable-libjpeg-turbo

# This option is required if you want to be able to run Gaia's tests
ac_add_options --enable-tests

# turn on mozTelephony/mozSms interfaces
# Only turn this line on if you actually have a dev phone
# you want to forward to. If you get crashes at startup,
# make sure this line is commented.
#ac_add_options --enable-b2g-ril

If you'd like to build with a packaged profile and include the b2g wrapper script, you can add the following to your mozconfig (with correct path):

GAIADIR=/path/to/gaia/repo

Note that if you add GAIADIR to your .mozconfig or change it after you have already built, then you will need to delete your object directory in order for GAIADIR to have any affect.

Then run make inside the mozilla-central directory:

$ make -f client.mk build

'''Note:''' Ensure you're using python2 and not python3 as the build will fail with python3.

The build will appear in ../build (or whatever MOZ_OBJDIR is set to in your .mozconfig) and will take a ''long'' time the first time you build.

==== Running gaia on B2G ====

On Linux, once it's built you can run B2G with:

# if you specified GAIADIR (e.g. Mozilla Nightlies)
$ ../build/dist/bin/b2g-bin -profile /path/to/gaia/profile

# if you did not specify GAIADIR
$ ../build/dist/bin/b2g -profile /path/to/gaia/profile

(substituting /path/to/gaia with the path to which you cloned Gaia).

On OSX, once it's built, you can run B2G with:

# if you specified GAIADIR (e.g. Mozilla Nightlies)
$ ../build/dist/B2G.app/Contents/MacOS/b2g-bin -profile /path/to/gaia/profile

# if you did not specify GAIADIR
$ ../build/dist/B2G.app/Contents/MacOS/b2g -profile /path/to/gaia/profile

When you want to update your own B2G Desktop build do:

$ hg pull && hg update
$ make -C ../build/b2g

In the gaia directory:

$ git pull

== Simulating Hardware Buttons ==

On a desktop B2G build, you don't have access to hardware buttons, but you can simulate them:

==== Linux / Windows ====
* Home button: Home key
* Power button: End key
* Volume button: Page Up/Down keys
* Open Cards View: long press to Home key

==== OS X ====
* Home button: fn + ← (fn + left arrow)
* Power button: fn + → (fn + right arrow)
* Volume button: fn + ↑/↓ (fn + up/down arrows)
* Open Cards View: cmd + fn + ← (cmd + fn + left arrow)

== B2G on a device ==

It is possible to build & run Firefox OS on a limited number of smartphones. Please see [https://github.com/mozilla-b2g/B2G/blob/master/README.md documentation here].

There is also [https://wiki.mozilla.org/B2G/DeveloperPhone#Gaia.2FB2G_Development_Environment documentation here] about testing changes on your device.

== Unit Tests ==

Gaia comes with a suite of unit tests, which you can run using the built-in Test Agent app (by running it in B2G desktop, B2G on a device, or by navigating to http://test-agent.gaiamobile.org:8080 in Firefox Nightly).

See [https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gecko/Gaia_Unit_Tests here] for more information on writing and running unit tests for Gaia.

== Filing Bugs ==
Bugs are filed on Bugzilla under [https://bugzilla.mozilla.org/buglist.cgi?product=Boot2Gecko&component=Gaia&resolution=--- Boot2Gecko > Gaia].

File a new bug under the Gaia component (or one of the sub-components) [https://bugzilla.mozilla.org/enter_bug.cgi?product=Boot2Gecko here]

== Contributing Code ==

Mozilla depends on contributions from the open source community to help develop Gaia apps and we'd love you to get involved.

Some great places to find some bugs to start hacking on:
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=component:gaia%20sw:polish%20@nobody;list_id=4566236 Unowned Gaia polish bugs on Bugzilla]
* [http://www.joshmatthews.net/bugsahoy/?b2g=1 Mentored bugs]

=== Submitting a Patch ===
* Assign an un-owned Gaia bug to yourself on [https://bugzilla.mozilla.org/buglist.cgi?product=Boot2Gecko&component=Gaia&resolution=--- Bugzilla] (you'll need a Bugzilla account).
* Fork [https://github.com/mozilla-b2g/gaia Gaia on Github] (you'll need a GitHub account) and clone your fork
$ git clone https://github.com/USERNAME/gaia.git gaia
* Develop in a branch on your fork (remembering to keep to the [https://wiki.mozilla.org/Gaia/Hacking#Coding_Style Coding Style guidelines] for Gaia)
$ git branch BRANCHNAME
$ git checkout BRANCHNAME
* Commit your changes
$ git add /FILE/TO/ADD
$ git commit -m "COMMIT MESSAGE INCLUDING BUG NUMBER"
* Push to your branch
$ git push origin BRANCHNAME
* Send a pull request by navigating to the branch in your fork on GitHub and finding the pull request button
* Paste a link to the pull request in the bug on Bugzilla
* Your patch will be reviewed on Github (if it isn't getting reviewed try asking around on IRC or the mailing list or commenting on the bug)
* To make changes in response to the code review, just push more commits to the same branch and your pull request will get updated automatically
$ git add /FILE/TO/ADD
$ git commit -m "COMMIT MESSAGE"
$ git push

(ideally squash all your changes into a single commit using git rebase)

* Once the reviewer is happy with your patch, they will merge it into the master branch for you

(ideally the commit message should have r=REVIEWER_NAME added to the commit message of a the squashed commit and your patch includes a passing unit test)

=== Reviewers ===

Gaia now has module owners and peers! For code reviews, ask any of the peers listed [https://wiki.mozilla.org/Modules/Boot2Gecko here].

=== Coding Style ===
* Background:
** [[MDC:Developer Guide/Coding Style#General practices]]
** [[MDC:Developer Guide/Coding Style#JavaScript practices]]
** [[MDC:Developer Guide/Coding Style#Naming and Formatting code]]

* make sure HTML files are declared <!DOCTYPE html> (i.e., HTML5). IE9+ will load them in compatibility mode otherwise.

* add a <code>"use strict";</code> statement (exactly that!) to the top of your JS files

* 2 spaces for indentation - do not use tab.

* Line break are free (I promise) don't hesitate to use them to separate logical block inside your functions.

* Files are named <code>like_this.js</code>.

* Use single quote instead of double quotes.

* Additional rules:
Bad:
if (expression) doSomething();

Correct:
if (expression)
doSomething();

=== System app ===

See here for some rules.
https://groups.google.com/d/msg/mozilla.dev.gaia/rEhSrw6XmT4/UNvE7qW9pgYJ

=== Before submitting a patch ===
On each javascript files you are adding or you have modified, run:
gjslint --nojsdoc my_file.js

http://code.google.com/closure/utilities/docs/linter_howto.html

Set of smoke tests to run before you check-in a patch:
[[media:PatchSmokeTests.pdf|PatchSmokeTests.pdf]]

== Contacting The Team ==
* [https://lists.mozilla.org/listinfo/dev-gaia Gaia Mailing List]
* #gaia IRC channel on irc.mozilla.org

== Tips ==
=== Linux B2G Desktop support ===

==== The homescreen is empty ====
Currently, under Linux, OOP (Out of Process) frame aren't rendered properly.
The homescreen isn't actually rendered here...

If you just want to happily hack on pure UI (css and JS) you can safely run with OOP disabled and avoid those issues.
Change the line in build/settings.py

"debug.oop.disabled": False,

to

"debug.oop.disabled": True,

Then rebuild your profile with

$ rm -r profile && make

=== Port Forwarding ===
To forward the socket on the phone to the desktop (for desktop development), you first need to get rilproxy to expose it as such, rather than exposing it to Gecko. In the gaia directory:

$ make forward

This runs the commands:
$ adb shell touch /data/local/rilproxyd
$ adb shell killall rilproxy
$ adb forward tcp:6200 localreserved:rilproxyd

The file located at /data/local/rilproxyd will be deleted once the rilproxy daemon will start again. As a consequence you have to do this manipulation every time your device restarts.

=== Restarting B2G on a device from the desktop ===
adb shell killall b2g

=== B2G Desktop JavaScript Console ===

You can run B2G Desktop with the JavaScript console by using the -jsconsole flag

$ /path/to/b2g-bin -jsconsole

=== Launching an app directly ===

A "--runapp" option has been added to the B2G Desktop command-line to automatically start an application. The system app is loaded and everything happens like normal; this is not like the old trick where we loaded your app instead of the system app.

"--runapp" takes an argument that it normalizes by lower-casing and removing dashes and spaces, and then checks the argument against the similarly normalized app names from app manifests. For example, the name of the e-mail app is currently "E-Mail", but "--runapp email" will run it. Partial matching is not supported right now, but you can enhance b2g/chrome/content/runapp.js if your app name is unwieldy.

If you invoke "--runapp" without an argument (or an empty argument), the command will print out a list of all the apps it knows about as well as a brief usage message.

One important note is that this command disables the lock-screen as part of its magic and does not re-enable it. The assumption is that you won't use this command on a profile where you are testing the lock screen, or will turn it back on manually. Feel free to enhance the command to behave better if this is a problem for you.

In summary:

./b2g -profile /path/to/your/gaia/profile --runapp email

runs the e-mail app.

=== reset-gaia and install-gaia make targets ===

The reset-gaia and install-gaia make targets can be used interchangeably. reset-gaia will purge all the existing profiles, database before push Gaia from your working directory (new setting database will also be initialized); install-gaia will just push updates of Gaia.

=== Blank screen when B2G Desktop starts ===
When you start b2g using b2g -profile $GAIA/profile a blank screen shows up and you see an error Cannot reach app://system.gaiamobile.org. To fix this there are a couple of things you can check

* Rebuild the gaia profile using DEBUG=1 make profile in the $GAIA directory
* Run b2g again
* If this doesn't fix it, check if there is any other process listening on port 8080. The default profile of gaia starts httpd.js, which listens on port 8080. When running a debug profile, b2g connects to localhost:8080. If some other process is running on port 8080, b2g will fail to display the home screen of gaia
** To find out if this is the case, you can enable logging on httpd.js. The httpd.js in the profile resides in this location - $GAIA/profile/extensions/httpd/content/httpd.js. Edit the variable var DEBUG=false; to change the DEBUG to true. Save the file and restart b2g. On the console now, you will be able to view the httpd's logs

=== Diagnosing OOM problems ===

[https://bugzilla.mozilla.org/show_bug.cgi?id=798747#c7 From Cjones]:

Another way to diagnose possible OOMs is to open a terminal and run

$ watch -n 1 'adb shell b2g-procrank'

If you see the "USS" of one of the app processes go up near 100MB and then that process disappear from the process list (accompanied by some sort of visual crash in gaia), then you've almost certainly seen an OOM kill.

Modules/Core

2012-07-31T19:42:12Z

Jorend: Add ejpbruel as a JS peer for the proxy code

{{Module
|name=Accessibility
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:ginn.chen@oracle.com Ginn Chen], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe]
|group=dev-accessibility
|source_dirs=accessible/
|url=http://www.mozilla.org/access/
|components=Core::Disability Access APIs
}}

{{Module
|name=Build and Release Tools
|description=Tools related to build and release automation and configuration of release builds.
|owner=[mailto:nrthomas@gmail.com Nick Thomas]
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:cmp@mozilla.org Chase Phillips], [mailto:mozpreed@sigkill.com John Paul Reed], [mailto:robert@roberthelmer.com Robert Helmer]
|group=dev-builds
|source_dirs=tools/botrunner.py, tools/build-environment/, tools/build/, tools/buildbot-configs/, tools/buildbot/, tools/buildbotcustom/, tools/l10n/, tools/MozBuild/, tools/patcher-configs/, tools/patcher/, tools/release/, tools/tinderbox-configs/, tools/tinderbox/, tools/update-packaging/, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/
|url=
|components=mozilla.org::Release Engineering, mozilla.org::Release Engineering: Custom Builds
}}

{{Module
|name=Build Config
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.
|owner=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:mark@moxienet.com Mark Mentovai], [mailto:me@kylehuey.com Kyle Huey], [mailto:mh@glandium.org Mike Hommey], [mailto:mitchell.field@live.com.au Mitchell Field], [mailto:wtc@google.com Wan-Teh Chang]
|group=dev-builds
|source_dirs=build/, config/, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/
|url=http://www.mozilla.org/build/
|components=Core::Build Config
}}

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

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

{{Module
|name=Cookies and Permissions
|description=
|owner=[mailto:dwitte@mozilla.com Dan Witte]
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher]
|group=dev-tech-network
|source_dirs=extensions/cookie/, netwerk/cookie/
|url=
|components=Core::Networking: Cookies
}}

{{Module
|name=docshell
|description=
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger],[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]
|group=dev-tech-layout
|source_dirs=docshell/, uriloader/, webshell/
|url=
|components=Core::Document Navigation
}}

{{Module
|name=Document Object Model
|description=
|owner=[mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:bent@mozilla.com Ben Turner], [mailto:mounir.lamouri@mozilla.com Mounir Lamouri], [mailto:khuey@kylehuey.com Kyle Huey], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:hsivonen@iki.fi Henri Sivonen]
|group=dev-tech-dom
|source_dirs=content/base/, content/events/, content/html/content/, content/html/document/, dom/%, dom/base/, dom/interfaces/, dom/locales/, dom/public/, dom/src/, dom/tests/
|url=http://developer.mozilla.org/en/docs/DOM
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML, Core::DOM: Events, Core::DOM: Mozilla Extensions, Core::DOM: Other, Core::DOM: Traversal-Range, Core::DOM: Validation
}}

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

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

{{Module
|name=Editor
|description=
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]
|peers=
|group=dev-platform
|source_dirs=editor/
|url=http://www.mozilla.org/editor/
|components=Core::Editor
}}

{{Module
|name=Embedding
|description=
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]
|group=dev-embedding
|source_dirs=embedding/
|url=
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging
}}

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

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

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

{{Module
|name=Graphics
|description=Mozilla graphics API
|owner=[mailto:jdrew@mozilla.com Joe Drew], [mailto:jrmuizel@mozilla.com Jeff Muizelaar]
|peers=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:bas.schouten@live.nl Bas Schouten], [mailto:bjacob@mozilla.com Benoit Jacob], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:ajuma@mozilla.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert], [mailto:george@mozilla.com George Wright], [mailto:mwoodrow@mozilla.com Matt Woodrow], [mailto:jdaggett@mozilla.com John Daggett], [mailto:jfkthame@googlemail.com Jonathan Kew]
|group=dev-platform
|source_dirs=gfx/, content/canvas/src/
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch
|components=Core::Graphics, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL
}}

{{Module
|name=GTK Embedding Widget
|description=Gtk Widget for embedding Mozilla into Gtk applications
|owner=[mailto:marco@gnome.org Marco Pesenti Gritti]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:dougt@meer.net Doug Turner]
|group=dev-embedding
|source_dirs=
|url=
|components=Core::Embedding: GTK Widget
}}

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

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

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

{{Module
|name=ImageLib
|description=
|owner=[mailto:joe@drew.ca Joe Drew]
|peers=[mailto:bobbyholley@gmail.com Bobby Holley], [mailto:netzen@gmail.com Brian Bondy], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:jlebar@mozilla.com Justin Lebar]
|group=dev-tech-gfx
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/
|url=
|components=Core::ImageLib
}}

{{Module
|name=IPC
|description=Message-passing between threads and processes
|owner=[mailto:cjones@mozilla.com Chris Jones]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner]
|group=dev-platform
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/
|url=
|components=Core::IPC}}

{{Module
|name=Java APIs for DOM
|description=APIs for Java access to the Document Object Model
|owner=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]
|peers=
|group=dev-tech-dom,dev-tech-java
|source_dirs=java/dom/
|url=http://www.mozilla.org/projects/blackwood/dom/
|components=Core::Java APIs for DOM
}}

{{Module
|name=Java APIs to WebShell
|description=
|owner=[mailto:edburns@acm.org Ed Burns]
|peers=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]
|group=dev-tech-java,dev-embedding
|source_dirs=java/webclient/
|url=http://www.mozilla.org/projects/blackwood/webclient/
|components=Core::Java APIs to WebShell
}}

{{Module
|name=Java Stubs
|description=OJI
|owner=[mailto:alfred.peng@sun.com Alfred Peng]
|peers=[mailto:Xiaobin.Lu@eng.Sun.com Xiaobin Lu]
|group=dev-tech-java
|source_dirs=modules/oji/, nav-java/, sun-java/
|url=http://www.mozilla.org/oji/
|components=
}}

{{Module
|name=Java to XPCOM Bridge
|description=
|owner=[mailto:pedemont@us.ibm.com Javier Pedemont]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|group=dev-tech-xpcom,dev-tech-java
|source_dirs=extensions/java
|url=http://www.mozilla.org/projects/blackwood/connect/
|components=Core::Java to XPCOM Bridge
}}

{{Module
|name=Java Utility Classes
|description=assert, debug, utilities, etc.
|owner=[mailto:edburns@acm.org Ed Burns]
|peers=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]
|group=dev-tech-java
|source_dirs=java/util/
|url=http://www.mozilla.org/projects/blackwood/java-util/
|components=
}}

{{Module
|name=Java-Implemented Plugins
|description=Infrastructure for writing MIME content-handlers
in Java.
|owner=[mailto:idk@eng.sun.com Igor Kushnirskiy]
|peers=
|group=dev-tech-java
|source_dirs=java/plugins/
|url=http://www.mozilla.org/projects/blackwood/java-plugins/
|components=Core::Java-Implemented Plugins
}}

{{Module
|name=JavaScript
|description=JavaScript Engine in C++ (SpiderMonkey)
|owner=[mailto:dmandelin@mozilla.com Dave Mandelin]
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], [mailto:gal@mozilla.com Andreas Gal], [mailto:cdleary@mozilla.com Chris Leary], , [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:jorendorff@mozilla.com Jason Orendorff], [mailto:jwalden@mit.edu Jeff Walden], [mailto:lwagner@mozilla.com Luke Wagner], [mailto:ejpbruel@mozilla.com Eddy Bruel] for proxies, [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:shaver@mozilla.org Mike Shaver]
|group=dev-tech-js-engine
|source_dirs=js/src/%, js/src/config/, js/src/editline/, js/src/fdlibm/
|url=http://www.mozilla.org/js/spidermonkey,
http://developer.mozilla.org/en/docs/About_JavaScript
|components=Core::JavaScript Engine
}}

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

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

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

{{Module
|name=Layout Engine
|description=rendering tree construction, layout (reflow), painting, etc.
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:bmlk@gmx.de Bernd Mielke], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron], [mailto:smontagu@smontagu.org Simon Montagu]
|group=dev-tech-layout
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/macbuild/, layout/printing/, layout/tables/, layout/tools/
|url=http://mozilla.org/newlayout/doc/ ,
http://lxr.mozilla.org/mozilla/source/layout/doc/
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Layout: View Rendering
}}

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

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

{{Module
|name=mfbt
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).
|owner=
|peers=
|group=dev-platform
|source_dirs=mfbt/
|url=
|components=Core::MFBT
}}

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

{{Module
|name=Necko
|description=The Mozilla Networking Library
|owner=[mailto:cbiesinger@gmail.com Christian Biesinger]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:pmcmanus@mozilla.com Patrick McManus], [mailto:bsmith@mozilla.com Brian Smith], [mailto:mnovotny@mozilla.com Michal Novotny]
|group=dev-tech-network
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets
}}

{{Module
|name=NSPR
|description=Netscape Portable Runtime
|owner=[mailto:nelson@bolyard.com Nelson Bolyard], [mailto:wtc@google.com Wan-Teh Chang]
|peers=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]
|group=dev-tech-nspr
|source_dirs=nsprpub/
|url=http://www.mozilla.org/projects/nspr/
http://www.mozilla.org/projects/nspr/reference/html/
http://www.mozilla.org/projects/nspr/release-notes/
|components=NSPR
}}

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

{{Module
|name=Plugins
|description= NPAPI Plugin support.
|owner=[mailto:joshmoz@gmail.com Josh Aas]
|peers=[mailto:jst@mozilla.org Johnny Stenback], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jmathies@mozilla.com Jim Mathies]
|group=
|source_dirs=dom/plugins/, modules/plugin/
|url=https://wiki.mozilla.org/Plugins
|components=Core::Java-Implemented Plugins, Core::Plug-ins
}}

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

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

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

{{Module
|name=Qt-based gfx and widget
|description=Qt-based rendering and widget code
|owner=[mailto:romaxa@gmail.com Oleg Romashin]
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:doug.turner@gmail.com Doug Turner]
|group=dev-tech-widget,dev-tech-gfx
|source_dirs=widget/qt/
|url=
|components=Core::Widget: Qt
}}

{{Module
|name=Radio Interface Layer
|description=Boot2Gecko Radio Interface Layer (RIL)
|owner=[mailto:philikon@mozilla.com Philipp von Weitershausen], [mailto:kmachulis@mozilla.com Kyle Machulis]
|peers=[mailto:marshall@mozilla.com Marshall Culpepper], [mailto:vyang@mozilla.com Vicamo Yang], [mailto:cjones@mozilla.com Chris Jones], [mailto:gal@mozilla.com Andreas Gal]
|group=dev-b2g
|source_dirs=ipc/ril dom/telephony
|url=https://wiki.mozilla.org/B2G/RIL
|components=Core::RIL
}}

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

{{Module
|name=Registry
|description=
|owner=[mailto:dveditz@cruzio.com Dan Veditz]
|peers=[mailto:dougt@meer.net Doug Turner]
|group=dev-tech-xpcom
|source_dirs=modules/libreg/
|url=
|components=
}}

{{Module
|name=security
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)
|owner=[mailto:nelson@bolyard.com Nelson Bolyard], [mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]
|peers=[mailto:alexei.volkov.bugs@sun.com Alexei Volkov], [mailto:christophe.ravel.bugs@sun.com Christophe Ravel], [mailto:emaldona@redhat.com Elio Maldonado], [mailto:glen.beasley@sun.com Glen Beasley], [mailto:julien.pierre.boogz@sun.com Julien Pierre], [mailto:kaie@kuix.de Kai Engert]
|group=dev-tech-crypto
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/
|url=http://mozilla.org/projects/security/pki/
|components=NSS, JSS, Core::Security, Core::Security: S/MIME
}}

{{Module
|name=Security - Mozilla PSM Glue
|description=Personal Security Manager
|owner=[mailto:kaie@kuix.de Kai Engert]
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]
|group=dev-tech-crypto
|source_dirs=security/manager/
|url=
|components=Core::Security: PSM, Core::Security: UI
}}

{{Module
|name=storage
|description=Storage APIs with a SQLite backend
|owner=[mailto:sdwilsh@shawnwilsher.com Shawn Wilsher]
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland]
|group=dev-platform
|source_dirs=db/sqlite3/, storage/
|url=http://developer.mozilla.org/en/docs/Storage
|components=Toolkit::Storage, Core::SQL
}}

{{Module
|name=String
|description=
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]
|group=dev-tech-xpcom
|source_dirs=string/, xpcom/string/
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide
|components=Core::String
}}

{{Module
|name=Style System
|description=CSS style sheet handling; style data computation
|owner=[mailto:dbaron@dbaron.org David Baron]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]
|group=dev-tech-layout
|source_dirs=layout/style/
|url=http://mozilla.org/newlayout/doc/
|components=Core::Style System (CSS)
}}

{{Module
|name=SVG
|description=Scalable Vector Graphics
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert]
|group=dev-tech-svg
|source_dirs=content/svg/, layout/svg/
|url=http://www.mozilla.org/projects/svg/
|components=Core::SVG
}}

{{Module
|name=Tamarin
|description=VM for ActionScript and JavaScript
|owner=[mailto:edwsmith@adobe.com Edwin Smith], [mailto:jodyer@adobe.com Jeff Dyer]
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]
|group=dev-tech-js-engine
|source_dirs=js/tamarin
|url=http://www.mozilla.org/projects/tamarin/
http://wiki.mozilla.org/tamarin/
http://hg.mozilla.org/tamarin-central/
http://hg.mozilla.org/tamarin-tracing/
|components=Tamarin
}}

{{Module
|name=Test Harness
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill and Marionette. Requests for new harnesses should go to Testing::General.
|owner=[mailto:ted@mozilla.com Ted Mielczarek]
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), [mailto:rcampbell@mozilla.com Rob Campbell] (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (mozmill), [mailto:mdas@mozilla.com Malini Das] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:jhammel@mozilla.com Jeffrey Hammel] (mozmill)
|group=dev-quality
|source_dirs=/testing
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js
}}

{{Module
|name=Testing Infrastructure
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker
|owner=[mailto:ctalbert@mozilla.com Clint Talbert]
|peers=[mailto:anodelman@mozilla.com Alice Nodelman], [mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], [mailto:rcampbell@mozilla.com Rob Campbell], [mailto:jhammel@mozilla.com Jeffrey Hammel], [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]
|group=dev-quality
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/
|url=http://wiki.mozilla.org/SoftwareTesting
|components=Testing::Infrastructure
}}

{{Module
|name=XPCShell Test Harness
|description=The XPCShell Harness
|owner=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]
|peers=[mailto:jmaher@mozilla.com Joel Maher]
|source_dirs=testing/xpcshell
|components=Testing::XPCShell Harness
}}

{{Module
|name=Update Service
|description=server code for Mozilla Update services (aus, addons, pfs)
|owner=[mailto:morgamic@mozilla.com Mike Morgan]
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]
|group=dev-amo
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/
|url=http://wiki.mozilla.org/wiki/AMO
|components=AUS::Administration, AUS::Systems
}}

{{Module
|name=View System
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]
|group=dev-tech-layout
|source_dirs=view/
|url=
|components=Core::Layout: View Rendering
}}

{{Module
|name=WebRTC
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access (on desktop at least)
|owner=[mailto:rjesup@mozilla.com Randell Jesup]
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:tterriberry@mozilla.com Tim Terriberry], [mailto:anant@mozilla.com Anant Narayanan]
|group=dev-media
|source_dirs=media/webrtc
|url=https://wiki.mozilla.org/Media/webrtc
|components=Core::WebRTC, Core::WebRTC (Audio/Video), Core::WebRTC (Networking), Core::WebRTC (Signaling)
}}

{{Module
|name=Widget
|description=
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-tech-gfx
|source_dirs=widget/%, widget/public/, widget/%, widget/xpwidgets/
|url=
|components=Core::Drag and Drop, Core::Widget
}}

{{Module
|name=Widget - Android
|description=The Android Port
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]
|peers=[mailto:vladimir@mozilla.com Vladimir Vukicevic], [mailto:dougt@dougt.org Doug Turner], [mailto:mwu@mozilla.com Michael Wu]
|group=dev-platform
|source_dirs=widget/android/, embedding/android
|url=
|components=Core::Widget: Android
}}

{{Module
|name=Widget - BeOS
|description=The BeOS port
|owner=[mailto:cbiesinger@gmail.com Christian Biesinger]
|peers=
|group=dev-tech-gfx
|source_dirs=widget/beos/
|url=http://www.bezilla.org/,
http://www.mozilla.org/ports/beos/
|components=Core::Widget: BeOS
}}

{{Module
|name=Widget - Gonk
|description=The Gonk Port (Boot2Gecko)
|owner=[mailto:mwu@mozilla.com Michael Wu]
|peers=[mailto:cjones@mozilla.com Chris Jones], [mailto:gal@mozilla.com Andreas Gal]
|group=dev-platform
|source_dirs=widget/gonk/
|url=http://wiki.mozilla.org/B2G
|components=Core::Widget: Gonk
}}

{{Module
|name=Widget - GTK
|description=supported X widgetry and gfx
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]
|peers=[mailto:karlt+@karlt.net Karl Tomlinson]
|group=dev-tech-gfx
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/
|components=Core::Widget: Gtk
}}

{{Module
|name=Widget - Mac OS X
|description= Gecko's Mac OS X compatibility layer.
|owner=[mailto:joshmoz@gmail.com Josh Aas]
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:smichaud@pobox.com Steven Michaud], [mailto:bgirard@mozilla.com Benoit Girard]
|group=dev-platform
|source_dirs=widget/cocoa/
|url=
|components=Core::Widget: Cocoa
}}

{{Module
|name=Widget - Windows
|description=Windows widgets and desktop integration
|owner=[mailto:jmathies@mozilla.com Jim Mathies]
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:dougt@meer.net Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:vladimir@pobox.com Vladimir Vukicevic]
|group=dev-platform
|source_dirs=widget/windows/
|url=
|components=Core::Widget: Win32
}}

{{Module
|name=XBL
|description=eXtensible Binding Language
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]
|peers=
|group=dev-tech-xbl
|source_dirs=content/xbl/%, content/xbl/public/, content/xbl/src/
|url=http://www.mozilla.org/projects/xbl/
|components=Core::XBL
}}

{{Module
|name=XML
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback], [mailto:sayrer@gmail.com Robert Sayre]
|group=dev-tech-xml
|source_dirs=content/xml/, extensions/xmlextras/, parser/expat/
|url=http://www.mozilla.org/newlayout/xml/
|components=Core::XML
}}

{{Module
|name=XPApps
|description=Cross-Platform Applications, mostly Navigator front end and application shell.
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:jag@tty.nl Peter Annema], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-apps-seamonkey
|source_dirs=xpfe/
|url=http://www.mozilla.org/xpapps/
|components=
}}

{{Module
|name=XPCOM
|description=The cross-platform object model and core data structures.
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|peers=[mailto:dougt@meer.net Doug Turner], [mailto:shaver@mozilla.org Mike Shaver]
|group=dev-platform
|source_dirs=startupcache/, tools/wizards/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/
|url=http://developer.mozilla.org/en/XPCOM
|components=Core::XPCOM
}}

{{Module
|name=XPConnect
|description=
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:gal@uci.edu Andreas Gal], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:bobbyholley@gmail.com Bobby Holley]
|group=
|source_dirs=js/xpconnect/
|url=
|components=Core::XPConnect
}}

{{Module
|name=XPIDL
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files. Also produces .java interface files, as part of an experimental java<->xpcom connection layer.
|owner=[mailto:BradleyJunk@cinci.rr.com BradleyJunk@cinci.rr.com]
|peers=[mailto:jband@netscape.com(disabled) jband@netscape.com(disabled)], [mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]
|group=dev-tech-xpcom
|source_dirs=xpcom/typelib/
|url=http://www.mozilla.org/scriptable/xpidl
http://www.mozilla.org/scriptable
|components=
}}

{{Module
|name=XPInstall
|description=
|owner=[mailto:dveditz@cruzio.com Dan Veditz]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]
|group=dev-tech-xpinstall
|source_dirs=xpinstall/
|url=
|components=Core::Installer: XPInstall Engine
}}

{{Module
|name=xptcall
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]
|group=dev-xpcom
|source_dirs=xpcom/reflect/xptcall/
|url=http://www.mozilla.org/scriptable/xptcall-faq.html
|components=
}}

{{Module
|name=XPToolkit
|description=Cross-platform user interface toolkit
|owner=
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:hyatt@mozilla.org Dave Hyatt], [mailto:jag@tty.nl Peter Annema], [mailto:Jan.Varga@gmail.com Jan Varga]
|group=dev-tech-xul
|source_dirs=content/xul/, layout/xul/
|url=http://www.mozilla.org/xpfe/
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL
}}

{{Module
|name=XSLT Processor
|description=XSLT transformations processor
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xslt
|source_dirs=content/xslt/
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html
|components=Core::XSLT
}}

{{Module
|name=XTF
|description=eXtensible Tag Framework
|owner=
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]
|group=dev-tech-xbl
|source_dirs=content/xtf/, layout/xtf/
|url=http://www.croczilla.com/bits_and_pieces/xtf/
|components=Core::XTF
}}

<noinclude>
===Unassigned Bugzilla Components===

The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):

<pre>
Core::Event Handling
Core::File Handling
Core::Find Backend
Core::Gecko Profiler
Core::General
Core::Hardware Abstraction Layer (HAL)
Core::HTML: Form Submission
Core::History: Global
Core::Identity
Core::Image Blocking
Core::JavaScript Debugging APIs
Core::Localization
Core::Nanojit
Core::Networking: Domain Lists
Core::Print Preview
Core::Printing: Output
Core::Printing: Setup
Core::Profile: BackEnd
Core::Profile: Migration
Core::Profile: Roaming
Core::QuickLaunch (AKA turbo mode)
Core::Rewriting and Analysis
Core::Selection
Core::Serializers
Core::Spelling checker
Core::Tracking
Core::Video/Audio
Core::Web Services
Core::WebDAV
Core::Widget: OS/2
Core::Widget: Photon
Core::X-remote
Core::XForms
Core::XUL
Core::jemalloc
</pre>
</noinclude>

Debugger

2012-05-08T17:07:33Z

Jorend:

This interface is partly implemented in Firefox Nightly builds. Some parts are not implemented, some APIs may yet change, and anything marked "(future plan)" is a long way off. You can [https://github.com/jimblandy/DebuggerDocs fork this specification on github] to draft and discuss revisions.

The <code>Debugger</code> constructor makes objects with methods for debugging code running in global objects in other compartments. Given a <code>Debugger</code> instance, you can:
<ul>
<li>add debuggee global objects to its purview using its <code>addDebuggee</code> method;
<li>request notification of basic debugging events like stack frame entry and <code>debugger</code> statement execution by providing appropriate handler functions;
<li>set breakpoints in scripts;
<li>set watchpoints on objects and their properties;
<li>examine the debuggee's stack frames and lexical enviroments;
<li>inspect and manipulate its objects;
</ul>
and so on.

Each global object may be debugged by any number of <code>Debugger</code> instances simultaneously.

Your event handling methods run in the same thread as the debuggee, on the same JavaScript stack: when the event occurs, the debuggee pauses while your handler methods run, and resumes (unless you say otherwise) when your methods return. Your event handling methods run in the compartment to which they belong, typically the debugger's compartment. The compartment system mediates the debugger's and debuggee's access to each other's objects.

The <code>Debugger</code> object provides various sorts of objects representing the debuggee's state, which the debugger code can examine and manipulate:
<ul>
<li><code>Debugger.Object</code> instances represent objects in the debuggee.
<li><code>Debugger.Frame</code> instances represent debuggee stack frames.
<li><code>Debugger.Script</code> instances represent the debuggee's code, whether it is a function body, code passed to <code>eval</code>, or a top-level script.
<li><code>Debugger.Environment</code> instances represent the variable environments in effect at different points in the debuggee's code.
</ul>

A <code>Debugger</code> instance can only debug code running in other compartments. You may not create cycles of debugger/debuggee compartments.

The <code>Debugger</code> interface does not itself support cross-thread or multi-threaded debugging. As a general rule, only one thread may use a compartment at a time. When a debugger in one compartment is debugging globals in another, many kinds of events in the debuggees may cause the debugger to call its handler methods. Conversely, a call to almost any method in this interface could cause the debugger to try to interact with a debuggee in some way. Thus, as a general rule, you should never permit different threads to run in the debugger and debuggee compartments simultaneously. Tools should instead use the [[Remote Debugging Protocol]] for all inter-thread communication.

== General Conventions ==

=== Properties ===

Properties of objects that comprise the <code>Debugger</code> interface, and those that the interface creates, follow some general conventions:
<ul>
<li>Instances and prototypes are extensible; you can add your own properties and methods to them.
<li>Properties are configurable. This applies to both "own" and prototype properties, and to both methods and data properties. (Leaving these properties open to redefinition will hopefully make it easier for JavaScript debugger code to cope with bugs, bug fixes, and changes in the interface over time.)
<li>Method properties are writable.
<li>We prefer inherited accessor properties to own data properties. Both are read using the same syntax, but inherited accessors seem like a more accurate reflection of what's going on. Unless otherwise noted, these properties have getters but no setters, as they cannot meaningfully be assigned to.
</ul>

=== Debuggee Values ===

The <code>Debugger</code> interface follows some conventions to help debuggers safely inspect and modify the debuggee's objects and values. Primitive values are passed freely between debugger and debuggee; copying or wrapping is handled transparently. Objects received from the debuggee (including host objects like DOM elements) are fronted in the debugger by <code>Debugger.Object</code> instances, which provide reflection-oriented methods for inspecting their referents; see <code>Debugger.Object</code>, below.

Of the debugger's objects, only <code>Debugger.Object</code> instances may be passed to the debuggee: when this occurs, the debuggee receives the <code>Debugger.Object</code>'s referent, not the <code>Debugger.Object</code> instance itself.

In the descriptions below, the term "debuggee value" means either a primitive value or a <code>Debugger.Object</code> instance; it is a value that might be received from the debuggee, or that could be passed to the debuggee.

=== Debuggee Code ===

Each <code>Debugger</code> instance maintains a set of global objects that, taken together, comprise the debuggee. Code evaluated in the scope of a debuggee global object, directly or indirectly, is considered debuggee code. Similarly:
<ul>
<li>a debuggee frame is a frame running debuggee code;
<li>a debuggee function is a function that closes over a debuggee global object (and thus the function's code is debuggee code); and
<li>a debuggee script is a script containing debuggee code.
</ul>

=== Completion Values ===

When a debuggee stack frame completes its execution, or when some sort of debuggee call initiated by the debugger finishes, the <code>Debugger</code> interface provides a value describing how the code completed; these are called completion values. A completion value has one of the following forms:
<dl>
<dt>{ return: value }
<dd>The code completed normally, returning value. Value is a debuggee value.
<dt>{ yield: value }
<dd>The running code is a generator frame which has yielded value. Value is a debuggee value.
<dt>{ throw: value }
<dd>The code threw value as an exception. Value is a debuggee value.
<dt>null
<dd>The code was terminated, as if by the "slow script" dialog box.
</dl>

If control reaches the end of a generator frame, the completion value is <code>{throw: stop}</code> where ''stop'' is a <code>Debugger.Object</code> object representing the <code>StopIteration</code> object being thrown.

=== Resumption Values ===

As the debuggee runs, the <code>Debugger</code> interface calls various debugger-provided handler functions to report the debuggee's behavior. Some of these calls can return a value indicating how the debuggee's execution should continue; these are called resumption values. A resumption value has one of the following forms:
<dl>
<dt>undefined
<dd>The debuggee should continue execution normally.
<dt>{ return: value }
<dd>Return value immediately as the current value of the function. Value must be a debuggee value. (Most handler functions support this, except those whose descriptions say otherwise.) If the function was called as a constructor (that is, via a <code>new</code> expression), then value serves as the value returned by the function's body, not that produced by the <code>new</code> expression: if the value is not an object, the <code>new</code> expression returns the frame's <code>this</code> value.
<dt>{ yield: value }
<dd>Yield value immediately as the next value of the current frame, which must be a generator frame. Value is a debuggee value. The current frame must be a generator frame that has not yet completed in some other way. You may use <code>yield</code> resumption values to substitute a new value or one already yielded by a generator, or to make a generator yield additional values.
<dt>{ throw: value }
<dd>Throw value as an execption from the current bytecode instruction. Value must be a debuggee value.
<dt>null
<dd>Terminate the debuggee, as if it had been cancelled by the "slow script" dialog box.
</dl>

If a function that would normally return a resumption value to indicate how the debuggee should continue instead throws an exception, we never propagate such an exception to the debuggee; instead, we call the associated <code>Debugger</code> instance's <code>uncaughtExceptionHook</code> property, as described below.

=== The Debugger.DebuggeeWouldRun Exception ===

Some debugger operations that appear to simply inspect the debuggee's state may actually cause debuggee code to run. For example, reading a variable might run a getter function on the global or on a <code>with</code> expression's operand; and getting an object's property descriptor will run a handler trap if the object is a proxy. To protect the debugger's integrity, only methods whose stated purpose is to run debuggee code can do so. These methods are called [[#Invocation_Functions_and_.22debugger.22_Frames|invocation functions]], and they follow certain common conventions to report the debuggee's behavior safely. For other methods, if their normal operation would cause debuggee code to run, they throw an instance of the <code>Debugger.DebuggeeWouldRun</code> exception.

A <code>Debugger.DebuggeeWouldRun</code> exception may have a <code>cause</code> property, providing more detailed information on why the debuggee would have run. The <code>cause</code> property's value is one of the following strings:

{| frame="box" rules="all" cellpadding="8"
! cause value
! meaning
|-
| "proxy"
| Carrying out the operation would have caused a proxy handler to run.
|-
| "getter"
| Carrying out the operation would have caused an object property getter to run.
|-
| "setter"
| Carrying out the operation would have caused an object property setter to run.
|}

If the system can't determine why control attempted to enter the debuggee, it will leave the exception's <code>cause</code> property undefined.

== The Debugger Object ==

When called as a constructor, the <code>Debugger</code> object creates a new <code>Debugger</code> instance.

<dl>
<dt>new Debugger([global, ...])
<dd>Create a debugger object, and apply its <code>addDebuggee</code> method to each of the given global objects to add them as the initial debuggees.
</dl>

=== Accessor Properties of the Debugger Prototype Object ===

A <code>Debugger</code> instance inherits the following accessor properties from its prototype:

<dl>
<dt>enabled
<dd>A boolean value indicating whether this <code>Debugger</code> instance's handlers, breakpoints, watchpoints, and the like are currently enabled. It is an accessor property with a getter and setter: assigning to it enables or disables this <code>Debugger</code> instance; reading it produces true if the instance is enabled, or false otherwise. This property is initially <code>true</code> in a freshly created <code>Debugger</code> instance.

This property gives debugger code a single point of control for disentangling itself from the debuggee, regardless of what sort of events or handlers or "points" we add to the interface.

<dt>uncaughtExceptionHook
<dd>Either <code>null</code> or a function that SpiderMonkey calls when a call to a debug event handler, breakpoint handler, watchpoint handler, or similar function throws some exception, debugger-exception. Exceptions thrown in the debugger are not propagated to debuggee code; instead, SpiderMonkey calls this function, passing debugger-exception as its sole argument and the <code>Debugger</code> instance as the <code>this</code> value. This function should return a [[#Resumption_Values|resumption value]], which determines how the debuggee should continue.

If the uncaught exception hook itself throws an exception, uncaught-hook-exception, SpiderMonkey throws a new error object, confess-to-debuggee-exception, to the debuggee whose message blames the debugger, and includes textual descriptions of uncaught-hook-exception and the original debugger-exception.

If <code>uncaughtExceptionHook</code>'s value is <code>null</code>, SpiderMonkey throws an exception to the debuggee whose message blames the debugger, and includes a textual description of debugger-exception.

Assigning anything other than a callable value or <code>null</code> to this property throws a <code>TypeError</code> exception.

(This is not an ideal way to handle debugger bugs, but the hope here is that some sort of backstop, even if imperfect, will make life easier for debugger developers. For example, an uncaught exception hook may have access to browser-level features like the <code>alert</code> function, which this API's implementation does not, making it possible to present debugger errors to the developer in a way suited to the context.)
</dl>

=== Debugger Handler Functions ===

Each <code>Debugger</code> instance inherits accessor properties with which you can store handler functions for SpiderMonkey to call when given events occur in debuggee code.

When one of the events described below occurs in debuggee code, the engine pauses the debuggee and calls the corresponding debugging handler on each <code>Debugger</code> instance that is observing the debuggee. The handler functions receive the <code>Debugger</code> instance as their <code>this</code> value. Most handler functions can return a [[#Resumption_Values|resumption value]] indicating how the debuggee's execution should proceed.

On a new <code>Debugger</code> instance, each of these properties is initially <code>undefined</code>. Any value assigned to a debugging handler must be either a function or undefined; otherwise a <code>TypeError</code> is thrown.

Handler functions run in the same thread in which the event occurred. They run in the compartment to which they belong, not in a debuggee compartment.

<dl>
<dt>onNewScript(script, global)
<dd>New code, represented by the <code>Debugger.Script</code> instance script, has been loaded in the scope of the debuggee global object global. global is a <code>Debugger.Object</code> instance whose referent is the global object.

This method's return value is ignored.

<dt>onDebuggerStatement(frame)
<dd>Debuggee code has executed a debugger statement in frame. This method should return a [[#Resumption_Values|resumption value]] specifying how the debuggee's execution should proceed.

<dt>onEnterFrame(frame)
<dd>The stack frame frame is about to begin executing code. (Naturally, frame is currently the youngest [[#Visible_Frames|visible frame]].) This method should return a [[#Resumption_Values|resumption value]] specifying how the debuggee's execution should proceed.

SpiderMonkey only calls <code>onEnterFrame</code> to report [[#Visible_Frames|visible]], non-<code>"debugger"</code> frames.

<dt>onThrow(frame, value) (future plan)
<dd>The exception value is being thrown by frame, which is running debuggee code. This method should return a [[#Resumption_Values|resumption value]] specifying how the debuggee's execution should proceed. If it returns <code>undefined</code>, the exception is thrown as normal.

A call to the <code>onThrow</code> handler is typically followed by one or more calls to the <code>onExceptionUnwind</code> handler.

''(pending discussion)'' If the debuggee executes <code>try { throw 0; } finally { f(); }</code> and <code>f()</code> executes without error, the <code>onThrow</code> handler is called only once. The debugger is not notified when the exception is set aside in order to execute the <code>finally</code> block, nor when it is restored after the <code>finally</code> block completes normally.

''(An alternative design here would be: onException(status, frame, value) where status is one of the strings "throw", "unwind", "catch", "finally", "rethrow". JS_SaveExceptionState would trigger a "finally" event, JS_RestoreExceptionState would trigger a "rethrow", JS_ClearPendingException would trigger a "catch"; not sure what JS_DropExceptionState or a return/throw from a finally block should do.)''

<dt>onExceptionUnwind(frame, value)
<dd>The exception value has been thrown, and has propagated to frame; frame is the youngest remaining stack frame, and is a debuggee frame. This method should return a [[#Resumption_Values|resumption value]] specifying how the debuggee's execution should proceed. If it returns <code>undefined</code>, the exception continues to propagate as normal: if control in <code>frame</code> is in a <code>try</code> block, control jumps to the corresponding <code>catch</code> or <code>finally</code> block; otherwise, frame is popped, and the exception propagates to frame's caller.

When an exception's propagation causes control to enter a <code>finally</code> block, the exception is temporarily set aside. If the <code>finally</code> block finishes normally, the exception resumes propagation, and the debugger's <code>onExceptionUnwind</code> handler is called again, in the same frame. (The other possibility is for the <code>finally</code> block to exit due to a <code>return</code>, <code>continue</code>, or <code>break</code> statement, or a new exception. In those cases the old exception does not continue to propagate; it is discarded.)

<dt>sourceHandler(ASuffusionOfYellow)
<dd>This method is never called. If it is ever called, a contradiction has been proven, and the debugger is free to assume that everything is true.

<dt>onError(frame, report)
<dd>SpiderMonkey is about to report an error in frame. Report is an object describing the error, with the following properties:

<dl>
<dt>message
<dd>The fully formatted error message.
<dt>file
<dd>If present, the source file name, URL, etc. (If this property is present, the line property will be too, and vice versa.)
<dt>line
<dd>If present, the source line number at which the error occurred.
<dt>lineText
<dd>If present, this is the source code of the offending line.
<dt>offset
<dd>The index of the character within lineText at which the error occurred.
<dt>warning
<dd>Present and true if this is a warning; absent otherwise.
<dt>strict
<dd>Present and true if this error or warning is due to the strict option (not to be confused with ES strict mode)
<dt>exception
<dd>Present and true if an exception will be thrown; absent otherwise.
<dt>arguments
<dd>An array of strings, representing the arguments substituted into the error message.
</dl>

This method's return value is ignored.
</dl>

=== Function Properties of the Debugger Prototype Object ===

The functions described below may only be called with a <code>this</code> value referring to a <code>Debugger</code> instance; they may not be used as methods of other kinds of objects.

<dl>
<dt>addDebuggee(global)
<dd>Add the global object designated by global to the set of global objects this <code>Debugger</code> instance is debugging. Return this <code>Debugger</code>'s <code>Debugger.Object</code> instance referring to global's referent.

One can use any of the following values to designate the global object to add as a debuggee:
<ul>
<li>a cross-compartment wrapper of a global object;
<li>a <code>Debugger.Object</code> instance belonging to this <code>Debugger</code> instance whose referent is a global object;
<li>a cross-compartment wrapper for any object, in which case the global in whose scope that object was allocated is used; or
<li>a <code>Debugger.Object</code> instance belonging to this <code>Debugger</code> instance whose referent is any object, in which case the global in whose scope that object was allocated is used.
</ul>

The global designated by global must be in a different compartment than this <code>Debugger</code> instance itself. If adding the designated global's compartment would create a cycle of debugger and debuggee compartments, this method throws an error.

If global is a cross-compartment wrapper, this method returns a <code>Debugger.Object</code> instance referring to the wrapper's referent. If global is a <code>Debugger.Object</code> instance belonging to this <code>Debugger</code> instance, this method returns global itself.

The <code>Debugger</code> instance does not hold a strong reference to its debuggee globals: if a debuggee global is not otherwise reachable, then it is dropped from the <code>Debugger</code>'s set of debuggees.

<dt>removeDebuggee(global)
<dd>Remove the global object designated by global from this <code>Debugger</code> instance's set of debuggees. Return <code>undefined</code>.

This method interprets global using the same rules that <code>addDebuggee</code> does.

<dt>hasDebuggee(global)
<dd>Return <code>true</code> if the global object designated by global is a debuggee of this <code>Debugger</code> instance.

This method interprets global using the same rules that <code>addDebuggee</code> does.

<dt>getDebuggees()
<dd>Return an array of distinct <code>Debugger.Object</code> instances whose referents are all the global objects this <code>Debugger</code> instance is debugging.

Since <code>Debugger</code> instances don't hold strong references to their debuggee globals, if a debuggee global is otherwise unreachable, it may be dropped at any moment from the array this method returns.

<dt>getNewestFrame()
<dd>Return a <code>Debugger.Frame</code> instance referring to the youngest [[#Visible_Frames|visible frame]] currently on the calling thread's stack, or <code>null</code> if there are no visible frames on the stack.

<dt>findScriptURLs([query])
<dd>Return an array containing the values of the <code>url</code> properties of all debuggee scripts matching query. Each distinct value appears only once in the array. Query is an object whose properties restrict which scripts are returned; a script must meet all the criteria given by query to be returned. If query is omitted, we return the <code>url</code> values of all debuggee scripts.

Query may have the following property:
<dl>
<dt>global
<dd>The script must be in the scope of the given global object. If this property's value is a <code>Debugger.Object</code> instance belonging to this <code>Debugger</code> instance, then its referent is used. If the object is not a global object, then the global in whose scope it was allocated is used.
</dl>

Note that the result may include values for scripts that can no longer ever be used by the debuggee, say, those for eval code that has finished running, or unreachable functions. Whether such script's <code>url</code> values appear can be affected by the garbage collector's behavior, so this function's behavior is not entirely deterministic.

<dt>findScripts([query])
<dd>Return an array of <code>Debugger.Script</code> instances for all debuggee scripts matching query. Each instance appears only once in the array. Query is an object whose properties restrict which scripts are returned; a script must meet all the criteria given by query to be returned. If query is omitted, we return the <code>Debugger.Script</code> instances for all debuggee scripts.

Query may have the following properties:
<dl>
<dt>url
<dd>The script's <code>url</code> property must be equal to this value.
<dt>line
<dd>The script must at least partially cover the given source line. If this property is present, the <code>url</code> property must be present as well.
<dt>column
<dd>The script must include given column on the line given by the <code>line</code> property. If this property is present, the <code>url</code> and <code>line</code> properties must both be present as well.
<dt>innermost
<dd>If this property is present and true, the script must be the innermost script covering the given source location; scripts of enclosing code are omitted.
<dt>global
<dd>The script must be in the scope of the given global object. If this property's value is a <code>Debugger.Object</code> instance belonging to this <code>Debugger</code> instance, then its referent is used. If the object is not a global object, then the global in whose scope it was allocated is used.
</dl>
All properties of query are optional. Passing an empty object returns all debuggee code scripts.

Note that the result may include <code>Debugger.Script</code> instances for scripts that can no longer ever be used by the debuggee, say, those for eval code that has finished running, or unreachable functions. Whether such scripts appear can be affected by the garbage collector's behavior, so this function's behavior is not entirely deterministic.

<dt>clearBreakpoint(handler)
<dd>Remove all breakpoints set in this <code>Debugger</code> instance that use handler as their handler. Note that, if breakpoints using other handler objects are set at the same location(s) as handler, they remain in place.

<dt>clearAllBreakpoints()
<dd>Remove all breakpoints set using this <code>Debugger</code> instance.

<dt>clearAllWatchpoints() (future plan)
<dd>Clear all watchpoints owned by this <code>Debugger</code> instance.

</dl>

== Debugger.Frame ==

A <code>Debugger.Frame</code> instance represents a [[#Visible_Frames|visible stack frame]]. Given a <code>Debugger.Frame</code> instance, you can find the script the frame is executing, walk the stack to older frames, find the lexical environment in which the execution is taking place, and so on.

For a given <code>Debugger</code> instance, SpiderMonkey creates only one <code>Debugger.Frame</code> instance for a given visible frame. Every handler method called while the debuggee is running in a given frame is given the same frame object. Similarly, walking the stack back to a previously accessed frame yields the same frame object as before. Debugger code can add its own properties to a frame object and expect to find them later, use <code>==</code> to decide whether two expressions refer to the same frame, and so on.

(If more than one <code>Debugger</code> instance is debugging the same code, each <code>Debugger</code> gets a separate <code>Debugger.Frame</code> instance for a given frame. This allows the code using each <code>Debugger</code> instance to place whatever properties it likes on its <code>Debugger.Frame</code> instances, without worrying about interfering with other debuggers.)

When the debuggee pops a stack frame (say, because a function call has returned or an exception has been thrown from it), the <code>Debugger.Frame</code> instance referring to that frame becomes inactive: its <code>live</code> property becomes <code>false</code>, and accessing its other properties or calling its methods throws an exception. Note that frames only become inactive at times that are predictable for the debugger: when the debuggee runs, or when the debugger removes frames from the stack itself.

Stack frames that represent the control state of generator-iterator objects behave in a special way, described in [[#Generator_Frames|Generator Frames]] below.

=== Visible Frames ===

When inspecting the call stack, <code>Debugger</code> does not reveal all the frames that are actually present on the stack: while it does reveal all frames running debuggee code, it omits frames running the debugger's own code, and omits most frames running non-debuggee code. We call those stack frames a <code>Debugger</code> does reveal visible frames.

A frame is a visible frame if any of the following are true:
<ul>
<li>it is running [[#debuggee_code|debuggee code]];
<li>its immediate caller is a frame running debuggee code; or
<li>it is a [[#Invocation_Functions_and_.22debugger.22_Frames|<code>"debugger"</code> frame]], representing the continuation of debuggee code invoked by the debugger.
</ul>

The "immediate caller" rule means that, when debuggee code calls a non-debuggee function, it looks like a call to a primitive: you see a frame for the non-debuggee function that was accessible to the debuggee, but any further calls that function makes are treated as internal details, and omitted from the stack trace. If the non-debuggee function eventually calls back into debuggee code, then those frames are visible.

(Note that the debuggee is not considered an "immediate caller" of handler methods it triggers. Even though the debuggee and debugger share the same JavaScript stack, frames pushed for SpiderMonkey's calls to handler methods to report events in the debuggee are never considered visible frames.)

=== Invocation Functions and "debugger" Frames ===

An invocation function is any function in this interface that allows the debugger to invoke code in the debuggee: <code>Debugger.Object.prototype.call</code>, <code>Debugger.Frame.prototype.eval</code>, and so on.

While invocation functions differ in the code to be run and how to pass values to it, they all follow this general procedure:

<ol>
<li>Let older be the youngest visible frame on the stack, or <code>null</code> if there is no such frame. (This is never one of the the debugger's own frames; those never appear as <code>Debugger.Frame</code> instances.)
<li>Push a <code>"debugger"</code> frame on the stack, with older as its <code>older</code> property.
<li>Invoke the debuggee code as appropriate for the given invocation function, with the <code>"debugger"</code> frame as its continuation. For example, <code>Debugger.Frame.prototype.eval</code> pushes an <code>"eval"</code> frame for code it runs, whereas <code>Debugger.Object.prototype.call</code> pushes a <code>"call"</code> frame.
<li>When the debuggee code completes, whether by returning, throwing an exception or being terminated, pop the <code>"debugger"</code> frame, and return an appropriate [[#Completion_Values|completion value]] from the invocation function to the debugger.
</ol>

When a debugger calls an invocation function to run debuggee code, that code's continuation is the debugger, not the next debuggee code frame. Pushing a <code>"debugger"</code> frame makes this continuation explicit, and makes it easier to find the extent of the stack created for the invocation.

=== Accessor Properties of the Debugger.Frame Prototype Object ===

A <code>Debugger.Frame</code> instance inherits the following accessor properties from its prototype:

<dl>
<dt>type
<dd>A string describing what sort of frame this is:
<ul>
<li><code>"call"</code>: a frame running a function call. (We may not be able to obtain frames for calls to host functions.)
<li><code>"eval"</code>: a frame running code passed to <code>eval</code>.
<li><code>"global"</code>: a frame running global code (JavaScript that is neither of the above).
<li><code>"debugger"</code>: a frame for a call to user code invoked by the debugger (see the <code>eval</code> method below).
</ul>

<dt>this
<dd>The value of <code>this</code> for this frame (a debuggee value).

<dt>older
<dd>The next-older visible frame, in which control will resume when this frame completes. If there is no older frame, this is <code>null</code>. (On a suspended generator frame, the value of this property is <code>null</code>; see [[#Generator_Frames|Generator Frames]].)

<dt>depth
<dd>The depth of this frame, counting from oldest to youngest; the oldest frame has a depth of zero.

<dt>live
<dd>True if the frame this <code>Debugger.Frame</code> instance refers to is still on the stack (or, in the case of generator-iterator objects, has not yet finished its iteration); false if it has completed execution or been popped in some other way.

<dt>script
<dd>The script being executed in this frame (a <code>Debugger.Script</code> instance), or <code>null</code> on frames that do not represent calls to debuggee code. On frames whose <code>callee</code> property is not null, this is equal to <code>callee.script</code>.

<dt>offset
<dd>The offset of the bytecode instruction currently being executed in <code>script</code>, or <code>undefined</code> if the frame's <code>script</code> property is <code>null</code>.

<dt>environment
<dd>The lexical environment within which evaluation is taking place (a <code>Debugger.Environment</code> instance), or <code>null</code> on frames that do not represent the evaluation of debuggee code, like calls non-debuggee functions, host functions or <code>"debugger"</code> frames.

<dt>callee
<dd>The function whose application created this frame, as a debuggee value, or <code>null</code> if this is not a <code>"call"</code> frame.

<dt>generator
<dd>True if this frame is a generator frame, false otherwise.

<dt>constructing
<dd>True if this frame is for a function called as a constructor, false otherwise.

<dt>arguments
<dd>The arguments passed to the current frame, or <code>null</code> if this is not a <code>"call"</code> frame. When non-<code>null</code>, this is an object, allocated in the same global as the debugger, with <code>Array.prototype</code> on its prototype chain, a non-writable <code>length</code> property, and properties whose names are array indices. Each property is a read-only accessor property whose getter returns the current value of the corresponding parameter. When the referent frame is popped, the argument value's properties' getters throw an error.
</dl>

=== Handler Methods of Debugger.Frame Instances ===

Each <code>Debugger.Frame</code> instance inherits accessor properties holding handler functions for SpiderMonkey to call when given events occur in the frame.

Calls to frames' handler methods are cross-compartment, intra-thread calls: the call takes place in the thread to which the frame belongs, and runs in the compartment to which the handler method belongs.

<code>Debugger.Frame</code> instances inherit the following handler method properties:

<dl>
<dt>onStep
<dd>This property must be either <code>undefined</code> or a function. If it is a function, SpiderMonkey calls it when execution in this frame makes a small amount of progress, passing no arguments and providing this <code>Debugger.Frame</code> instance as the <code>this</code>value. The function should return a [[#Resumption_Values|resumption value]] specifying how the debuggee's execution should proceed.

What constitutes "a small amount of progress" varies depending on the implementation, but it is fine-grained enough to implement useful "step" and "next" behavior.

If multiple <code>Debugger</code> instances each have <code>Debugger.Frame</code> instances for a given stack frame with <code>onStep</code> handlers set, their handlers are run in an unspecified order. If any <code>onStep</code> handler forces the frame to return early (by returning a resumption value other than <code>undefined</code>), any remaining debuggers' <code>onStep</code> handlers do not run.

This property is ignored on frames that are not executing debuggee code, like <code>"call"</code> frames for calls to host functions and <code>"debugger"</code> frames.

<dt>onPop
<dd>This property must be either <code>undefined</code> or a function. If it is a function, SpiderMonkey calls it just before this frame is popped, passing a [[#Completion_Values|completion value]] indicating how this frame's execution completed, and providing this <code>Debugger.Frame</code> instance as the <code>this</code> value. The function should return a [[#Resumption_Values|resumption value]] indicating how execution should proceed. On newly created frames, this property's value is <code>undefined</code>.

When an <code>onPop</code> call reports the completion of a construction call (that is, a function called via the <code>new</code> operator), the completion value passed to the handler describes the value returned by the function body. If this value is not an object, it may be different from the value produced by the <code>new</code> expression, which will be the value of the frame's <code>this</code> property. (In ECMAScript terms, the <code>onPop</code> handler receives the value returned by the <code><nowiki>[[Call]]</nowiki></code> method, not the value returned by the <code><nowiki>[[Construct]]</nowiki></code> method.)

When a debugger handler function forces a frame to complete early, by returning a <code>{ return:... }</code>, <code>{ throw:... }</code>, or <code>null</code> resumption value, SpiderMonkey calls the frame's <code>onPop</code> handler, if any. The completion value passed in this case reflects the resumption value that caused the frame to complete.

When SpiderMonkey calls an <code>onPop</code> handler for a frame that is throwing an exception or being terminated, and the handler returns <code>undefined</code>, then SpiderMonkey proceeds with the exception or termination. That is, an <code>undefined</code> resumption value leaves the frame's throwing and termination process undisturbed.

When a generator frame yields a value, SpiderMonkey calls its <code>Debugger.Frame</code> instance's <code>onPop</code> handler method, if present, passing a <code>yield</code> resumption value; however, the <code>Debugger.Frame</code> instance remains live.

If multiple <code>Debugger</code> instances each have <code>Debugger.Frame</code> instances for a given stack frame with <code>onPop</code> handlers set, their handlers are run in an unspecified order. The resumption value each handler returns establishes the completion value reported to the next handler.

This property is ignored on <code>"debugger"</code> frames.

<dt>onResume(value)
<dd>This property must be either <code>undefined</code> or a function. If it is a function, SpiderMonkey calls it if the current frame is a generator frame whose execution has just been resumed. The function should return a [[#Resumption_Values|resumption value]] indicating how execution should proceed. On newly created frames, this property's value is <code>undefined</code>.

If the program resumed the generator by calling its <code>send</code> method and passing a value, then value is that value. Otherwise, value is <code>undefined</code>.
</dl>

=== Function Properties of the Debugger.Frame Prototype Object ===

The functions described below may only be called with a <code>this</code> value referring to a <code>Debugger.Frame</code> instance; they may not be used as methods of other kinds of objects.

<dl>
<dt>eval(code)
<dd>Evaluate code in the execution context of this frame, and return a [[#Completion_Values|completion value]] describing how it completed. Code is a string. If this frame's <code>environment</code> property is <code>null</code>, throw a <code>TypeError</code>. All extant handler methods, breakpoints, watchpoints, and so on remain active during the call. This function follows the [[#Invocation_Functions_and_.22debugger.22_Frames|invocation function conventions]].

Code is interpreted as strict mode code when it contains a Use Strict Directive, or the code executing in this frame is strict mode code.

If code is not strict mode code, then variable declarations in code affect the environment of this frame. (In the terms used by the ECMAScript specification, the <code>VariableEnvironment</code> of the execution context for the eval code is the <code>VariableEnvironment</code> of the execution context that this frame represents.) If implementation restrictions prevent SpiderMonkey from extending this frame's environment as requested, this call throws an Error exception.

<dt>evalWithBindings(code, bindings)
<dd>Like <code>eval</code>, but evaluate code in the environment of this frame, extended with bindings from the object bindings. For each own enumerable property of bindings named name whose value is value, include a variable in the environment in which code is evaluated named name, whose value is value. Each value must be a debuggee value. (This is not like a <code>with</code> statement: code may access, assign to, and delete the introduced bindings without having any effect on the bindings object.)

This method allows debugger code to introduce temporary bindings that are visible to the given debuggee code and which refer to debugger-held debuggee values, and do so without mutating any existing debuggee environment.

Note that, like <code>eval</code>, declarations in the code passed to <code>evalWithBindings</code> affect the environment of this frame, even as that environment is extended by bindings visible within code. (In the terms used by the ECMAScript specification, the <code>VariableEnvironment</code> of the execution context for the eval code is the <code>VariableEnvironment</code> of the execution context that this frame represents, and the bindings appear in a new declarative environment, which is the eval code's <code>LexicalEnvironment</code>.) If implementation restrictions prevent SpiderMonkey from extending this frame's environment as requested, this call throws an <code>Error</code> exception.

<dt>pop(completion) (future plan)
<dd>Pop this frame (and any younger frames) from the stack as if this frame had completed as specified by the completion value completion.

Note that this does not resume the debuggee's execution; it merely adjusts the debuggee's state to what it would be if this frame's execution had completed. The debuggee will only resume execution when you return from the handler method that brought control to the debugger originally.

This cannot remove any <code>"call"</code> frames for calls to host functions from the stack. (We might be able to make this work eventually, but it will take some cleverness.)

<dt>replaceCall(function, this, arguments) (future plan)
<dd>Pop any younger frames from the stack, and then change this frame into a frame for a call to function, with the given this value and arguments. This should be a debuggee value, or <code>{ asConstructor: true }</code> to invoke function as a constructor, in which case SpiderMonkey provides an appropriate <code>this</code> value itself. Arguments should be an array of debuggee values. This frame must be a <code>"call"</code> frame.

This can be used as a primitive in implementing some forms of a "patch and continue" debugger feature.

Note that this does not resume the debuggee's execution; it merely adjusts the debuggee's state to what it would be if this frame were about to make this call. The debuggee will only resume execution when you return from the handler method that brought control to the debugger originally.

Like <code>pop</code>, this cannot remove <code>"call"</code> frames for calls to host functions from the stack.

</dl>

=== Generator Frames ===

SpiderMonkey supports generator-iterator objects, which produce a series of values by repeatedly suspending the execution of a function or expression. For example, calling a function that uses <code>yield</code> produces a generator-iterator object, as does evaluating a generator expression like <code>(i*i for each (i in [1,2,3]))</code>.

A generator-iterator object refers to a stack frame with no fixed continuation frame. While the generator's code is running, its continuation is whatever frame called its <code>next</code> method; while the generator is suspended, it has no particular continuation frame; and when it resumes again, the continuation frame for that resumption could be different from that of the previous resumption.

A <code>Debugger.Frame</code> instance representing a generator frame differs from an ordinary stack frame as follows:
<ul>
<li>A generator frame's <code>generator</code> property is true.
<li>A generator frame disappears from the stack each time the generator yields a value and is suspended, and reappears atop the stack when it is resumed to produce the generator's next value. The same <code>Debugger.Frame</code> instance refers to the generator frame until it returns, throws an exception, or is terminated.
<li>A generator frame's <code>older</code> property refers to the frame's continuation frame while the generator is running, and is <code>null</code> while the generator is suspended.
<li>A generator frame's <code>depth</code> property reflects the frame's position on the stack when the generator is resumed, and is <code>null</code> while the generator is suspended.
<li>A generator frame's <code>live</code> property remains true until the frame returns, throws an exception, or is terminated. Thus, generator frames can be live while not present on the stack.
</ul>

The other <code>Debugger.Frame</code> methods and accessor properties work as described on generator frames, even when the generator frame is suspended. You may examine a suspended generator frame's variables, and use its <code>script</code> and <code>offset</code> members to see which <code>yield</code> it is suspended at.

A <code>Debugger.Frame</code> instance referring to a generator-iterator frame has a strong reference to the generator-iterator object; the frame (and its object) will live as long as the <code>Debugger.Frame</code> instance does. However, when the generator function returns, throws an exception, or is terminated, thus ending the iteration, the <code>Debugger.Frame</code> instance becomes inactive and its <code>live</code> property becomes <code>false</code>, just as would occur for any other sort of frame that is popped. A non-live <code>Debugger.Frame</code> instance no longer holds a strong reference to the generator-iterator object.

== Debugger.Script ==

A <code>Debugger.Script</code> instance refers to a sequence of bytecode in the debuggee; it is the JavaScript-level presentation of a JSAPI <code>JSScript</code> object. Each of the following is represented by single JSScript object:
<ul>
<li>The body of a function—that is, all the code in the function that is not contained within some nested function.
<li>The code passed to a single call to <code>eval</code>, excluding the bodies of any functions that code defines.
<li>The contents of a <code><script></code> element.
<li>A DOM event handler, whether embedded in HTML or attached to the element by other JavaScript code.
<li>Code appearing in a <code>javascript:</code> URL.
</ul>

The <code>Debugger</code> interface constructs <code>Debugger.Script</code> objects as scripts of debuggee code are uncovered by the debugger: via the <code>onNewScript</code> handler method; via <code>Debugger.Frame</code>'s <code>script</code> properties; via the <code>functionScript</code> method of <code>Debugger.Object</code> instances; and so on. For a given <code>Debugger</code> instance, SpiderMonkey constructs exactly one <code>Debugger.Script</code> instance for each underlying script object; debugger code can add its own properties to a script object and expect to find them later, use <code>==</code> to decide whether two expressions refer to the same script, and so on.

(If more than one <code>Debugger</code> instance is debugging the same code, each <code>Debugger</code> gets a separate <code>Debugger.Script</code> instance for a given script. This allows the code using each <code>Debugger</code> instance to place whatever properties it likes on its <code>Debugger.Script</code> instances, without worrying about interfering with other debuggers.)

A <code>Debugger.Script</code> instance is a strong reference to a JSScript object; it protects the script it refers to from being garbage collected.

Note that SpiderMonkey may use the same <code>Debugger.Script</code> instances for equivalent functions or evaluated code—that is, scripts representing the same source code, at the same position in the same source file, evaluated in the same lexical environment.

=== Accessor Properties of the Debugger.Script Prototype Object ===

A <code>Debugger.Script</code> instance inherits the following accessor properties from its prototype:

<dl>
<dt>url
<dd>The filename or URL from which this script's code was loaded.

<dt>startLine
<dd>The number of the line at which this script's code starts, within the file or document named by <code>url</code>.

<dt>lineCount
<dd>The number of lines this script's code occupies, within the file or document named by <code>url</code>.

<dt>staticLevel
<dd>The number of function bodies enclosing this script's code.

Global code is at level zero; bodies of functions defined at the top level in global code are at level one; bodies of functions nested within those are at level two; and so on.

A script for code passed to direct <code>eval</code> is at a static level one greater than that of the script containing the call to <code>eval</code>, because direct eval code runs within the caller's scope. However, a script for code passed to an indirect <code>eval</code> call is at static level zero, since it is evaluated in the global scope.

Note that a generator's expressions are considered to be part of the body of a synthetic function, produced by the compiler.

Scripts' static level be useful in deciding where to set breakpoints. For example, a breakpoint set on line 3 in this code:

function f() {
x = function g() { // line 2
// line 3; no code here
...;
}
}

should be set in <code>g</code>'s script, not in <code>f</code>'s, even though neither script contains code at that line. In such a case, the most deeply nested script—the one with the highest static level—should receive the breakpoint.

<dt>strictMode
<dd>This is <code>true</code> if this script's code is ECMAScript strict mode code, and <code>false</code> otherwise.
</dl>

=== Function Properties of the Debugger.Script Prototype Object ===

The functions described below may only be called with a <code>this</code> value referring to a <code>Debugger.Script</code> instance; they may not be used as methods of other kinds of objects.

<dl>
<dt>decompile([pretty])
<dd>Return a string containing JavaScript source code equivalent to this script in its effect and result. If pretty is present and true, produce indented code with line breaks.

(Note that <code>Debugger.Object</code> instances referring to functions also have a <code>decompile</code> method, whose result includes the function header and parameter names, so it is probably better to write <code>f.decompile()</code> than to write <code>f.getFunctionScript().decompile()</code>.)

<dt>getAllOffsets()
<dd>Return an array L describing the relationship between bytecode instruction offsets and source code positions in this script. L is sparse, and indexed by source line number. If a source line number line has no code, then L has no line property. If there is code for line, then <code>L[line]</code> is an array of offsets of byte code instructions that are entry points to that line.

For example, suppose we have a script for the following source code:
a=[]
for (i=1; i < 10; i++)
// It's hip to be square.
a[i] = i*i;

Calling <code>getAllOffsets()</code> on that code might yield an array like this:
[[0], [5, 20], , [10]]

This array indicates that:
<ul>
<li>the first line's code starts at offset 0 in the script;
<li>the <code>for</code> statement head has two entry points at offsets 5 and 20 (for the initialization, which is performed only once, and the loop test, which is performed at the start of each iteration);
<li>the third line has no code;
<li>and the fourth line begins at offset 10.
</ul>

<dt>getLineOffsets(line)
<dd>Return an array of bytecode instruction offsets representing the entry points to source line line. If the script contains no executable code at that line, the array returned is empty.

<dt>getOffsetLine(offset)
<dd>Return the source code line responsible for the bytecode at offset in this script.

<dt>getChildScripts()
<dd>Return a new array whose elements are Debugger.Script objects for each function and each generator expression in this script. Only direct children are included; nested children can be reached by walking the tree.

<dt>setBreakpoint(offset, handler)
<dd>Set a breakpoint at the bytecode instruction at offset in this script, reporting hits to the <code>hit</code> method of handler. If offset is not a valid offset in this script, throw an error.

When execution reaches the given instruction, SpiderMonkey calls the <code>hit</code> method of handler, passing a <code>Debugger.Frame</code> instance representing the currently executing stack frame. The <code>hit</code> method's return value should be a [[#Resumption_Values|resumption value]], determining how execution should continue.

Any number of breakpoints may be set at a single location; when control reaches that point, SpiderMonkey calls their handlers in an unspecified order.

Any number of breakpoints may use the same handler object.

Breakpoint handler method calls are cross-compartment, intra-thread calls: the call takes place in the same thread that hit the breakpoint, and in the compartment containing the handler function (typically the debugger's compartment).

The new breakpoint belongs to the <code>Debugger</code> instance to which this script belongs; disabling the <code>Debugger</code> instance disables this breakpoint.

<dt>getBreakpoints([offset])
<dd>Return an array containing the handler objects for all the breakpoints set at offset in this script. If offset is omitted, return the handlers of all breakpoints set anywhere in this script. If offset is present, but not a valid offset in this script, throw an error.

<dt>clearBreakpoints(handler, [offset])
<dd>Remove all breakpoints set in this <code>Debugger</code> instance that use handler as their handler. If offset is given, remove only those breakpoints set at offset that use handler; if offset is not a valid offset in this script, throw an error.

Note that, if breakpoints using other handler objects are set at the same location(s) as handler, they remain in place.

<dt>clearAllBreakpoints([offset])
<dd>Remove all breakpoints set in this script. If offset is present, remove all breakpoints set at that offset in this script; if offset is not a valid bytecode offset in this script, throw an error.

</dl>

== Debugger.Object ==

A <code>Debugger.Object</code> instance represents an object in the debuggee, providing reflection-oriented methods to inspect and modify its referent. The referent's properties do not appear directly as properties of the <code>Debugger.Object</code> instance; the debugger can access them only through methods like <code>Debugger.Object.prototype.getOwnPropertyDescriptor</code> and <code>Debugger.Object.prototype.defineProperty</code>, ensuring that the debugger will not inadvertently invoke the referent's getters and setters.

SpiderMonkey creates exactly one <code>Debugger.Object</code> instance for each debuggee object it presents to a given <code>Debugger</code> instance: if the debugger encounters the same object through two different routes (perhaps two functions are called on the same object), SpiderMonkey presents the same <code>Debugger.Object</code> instance to the debugger each time. This means that the debugger can use the <code>==</code> operator to recognize when two <code>Debugger.Object</code> instances refer to the same debuggee object, and place its own properties on a <code>Debugger.Object</code> instance to store metadata about particular debuggee objects.

(If more than one <code>Debugger</code> instance is debugging the same code, each <code>Debugger</code> gets a separate <code>Debugger.Object</code> instance for a given object. This allows the code using each <code>Debugger</code> instance to place whatever properties it likes on its own <code>Debugger.Object</code> instances, without worrying about interfering with other debuggers.)

While most <code>Debugger.Object</code> instances are created by SpiderMonkey in the process of exposing debuggee's behavior and state to the debugger, the debugger can use <code>Debugger.Object.prototype.makeDebuggeeValue</code> to create <code>Debugger.Object</code> instances for given debuggee objects, or use <code>Debugger.Object.prototype.copy</code> and <code>Debugger.Object.prototype.create</code> to create new objects in debuggee compartments, allocated as if by particular debuggee globals.

<code>Debugger.Object</code> instances protect their referents from the garbage collector; as long as the <code>Debugger.Object</code> instance is live, the referent remains live. This means that garbage collection has no visible effect on <code>Debugger.Object</code> instances.

=== Accessor Properties of the Debugger.Object prototype ===

A <code>Debugger.Object</code> instance inherits the following accessor properties from its prototype:

<dl>
<dt>proto
<dd>The referent's prototype (as a new <code>Debugger.Object</code> instance), or <code>null</code> if it has no prototype.

<dt>class
<dd>A string naming the ECMAScript <code><nowiki>[[Class]]</nowiki></code> of the referent.

<dt>callable
<dd><code>true</code> if the referent is a callable object (such as a function or a function proxy); false otherwise.

<dt>name
<dd>If the referent is a function, its function name. If the referent is an anonymous function, or not a function at all, this is <code>undefined</code>.

<dt>parameterNames
<dd>If the referent is a function, the names of the its parameters, as an array of strings. If the referent is not a function at all, this is <code>undefined</code>.

If the referent is a host function for which parameter names are not available, return an array with one element per parameter, each of which is <code>undefined</code>.

If the referent is a function proxy, return an empty array.

If the referent uses destructuring parameters, then the array's elements reflect the structure of the parameters. For example, if the referent is a function declared in this way:

function f(a, [b, c], {d, e:f}) { ... }

then this <code>Debugger.Object</code> instance's <code>parameterNames</code> property would have the value:

["a", ["b", "c"], {d:"d", e:"f"}]

<dt>script
<dd>If the referent is a function that is debuggee code, this is that function's script, as a <code>Debugger.Script</code> instance. If the referent is a function proxy or not debuggee code, this is <code>undefined</code>.

<dt>environment
<dd>If the referent is a function that is debuggee code, a <code>Debugger.Environment</code> instance representing the lexical environment enclosing the function when it was created. If the referent is a function proxy or not debuggee code, this is <code>undefined</code>.

<dt>proxyHandler
<dd>If the referent is a proxy whose handler object was allocated by debuggee code, this is its handler object—the object whose methods are invoked to implement accesses of the proxy's properties. If the referent is not a proxy whose handler object was allocated by debuggee code, this is <code>null</code>.

<dt>proxyCallTrap
<dd>If the referent is a function proxy whose handler object was allocated by debuggee code, this is its call trap function—the function called when the function proxy is called. If the referent is not a function proxy whose handler object was allocated by debuggee code, this is <code>null</code>.

<dt>proxyConstructTrap
<dd>If the referent is a function proxy whose handler object was allocated by debuggee code, its construction trap function—the function called when the function proxy is called via a <code>new</code> expression. If the referent is not a function proxy whose handler object was allocated by debuggee code, this is <code>null</code>.

</dl>

=== Function Properties of the Debugger.Object prototype ===

The functions described below may only be called with a <code>this</code> value referring to a <code>Debugger.Object</code> instance; they may not be used as methods of other kinds of objects. The descriptions use "referent" to mean "the referent of this <code>Debugger.Object</code> instance".

Unless otherwise specified, these methods are not [[#Invocation_Functions_and_.22debugger.22_Frames|invocation functions]]; if a call would cause debuggee code to run (say, because it gets or sets an accessor property whose handler is debuggee code, or because the referent is a proxy whose traps are debuggee code), the call throws a [[#The_Debugger.DebuggeeWouldRun_Exception|<code>Debugger.DebuggeeWouldRun</code>]] exception.

<dl>
<dt>getProperty(name)
<dd>Return the value of the referent's property named name, or <code>undefined</code> if it has no such property. Name must be a string. The result is a debuggee value.

<dt>setProperty(name, value)
<dd>Store value as the value of the referent's property named name, creating the property if it does not exist. Name must be a string; value must be a debuggee value.

<dt>getOwnPropertyDescriptor(name)
<dd>Return a property descriptor for the property named name of the referent. If the referent has no such property, return <code>undefined</code>. (This function behaves like the standard <code>Object.getOwnPropertyDescriptor</code> function, except that the object being inspected is implicit; the property descriptor returned is allocated as if by code scoped to the debugger's global object (and is thus in the debugger's compartment); and its <code>value</code>, <code>get</code>, and <code>set</code> properties, if present, are debuggee values.)

<dt>getOwnPropertyNames()
<dd>Return an array of strings naming all the referent's own properties, as if <code>Object.getOwnPropertyNames(referent)</code> had been called in the debuggee, and the result copied in the scope of the debugger's global object.

<dt>defineProperty(name, attributes)
<dd>Define a property on the referent named name, as described by the property descriptor descriptor. Any <code>value</code>, <code>get</code>, and <code>set</code> properties of attributes must be debuggee values. (This function behaves like <code>Object.defineProperty</code>, except that the target object is implicit, and in a different compartment from the function and descriptor.)

<dt>defineProperties(properties)
<dd>Add the properties given by properties to the referent. (This function behaves like <code>Object.defineProperties</code>, except that the target object is implicit, and in a different compartment from the properties argument.)

<dt>deleteProperty(name)
<dd>Remove the referent's property named name. Return true if the property was successfully removed, or if the referent has no such property. Return false if the property is non-configurable.

<dt>seal()
<dd>Prevent properties from being added to or deleted from the referent. Return this <code>Debugger.Object</code> instance. (This function behaves like the standard <code>Object.seal</code> function, except that the object to be sealed is implicit and in a different compartment from the caller.)

<dt>freeze()
<dd>Prevent properties from being added to or deleted from the referent, and mark each property as non-writable. Return this <code>Debugger.Object</code> instance. (This function behaves like the standard <code>Object.freeze</code> function, except that the object to be sealed is implicit and in a different compartment from the caller.)

<dt>preventExtensions()
<dd>Prevent properties from being added to the referent. (This function behaves like the standard <code>Object.preventExtensions</code> function, except that the object to operate on is implicit and in a different compartment from the caller.)

<dt>isSealed()
<dd>Return true if the referent is sealed—that is, if it is not extensible, and all its properties have been marked as non-configurable. (This function behaves like the standard <code>Object.isSealed</code> function, except that the object inspected is implicit and in a different compartment from the caller.)

<dt>isFrozen()
<dd>Return true if the referent is frozen—that is, if it is not extensible, and all its properties have been marked as non-configurable and read-only. (This function behaves like the standard <code>Object.isFrozen</code> function, except that the object inspected is implicit and in a different compartment from the caller.)

<dt>isExtensible()
<dd>Return true if the referent is extensible—that is, if it can have new properties defined on it. (This function behaves like the standard <code>Object.isExtensible</code> function, except that the object inspected is implicit and in a different compartment from the caller.)

<dt>copy(value)
<dd>Apply the HTML5 "structured cloning" algorithm to create a copy of value in the referent's global object (and thus in the referent's compartment), and return a <code>Debugger.Object</code> instance referring to the copy.

Note that this returns primitive values unchanged. This means you can use <code>Debugger.Object.prototype.copy</code> as a generic "debugger value to debuggee value" conversion function—within the limitations of the "structured cloning" algorithm.

<dt>create(prototype, [properties])
<dd>Create a new object in the referent's global (and thus in the referent's compartment), and return a <code>Debugger.Object</code> referring to it. The new object's prototype is prototype, which must be an <code>Debugger.Object</code> instance. The new object's properties are as given by properties, as if properties were passed to <code>Debugger.Object.prototype.defineProperties</code>, with the new <code>Debugger.Object</code> instance as the <code>this</code> value.

<dt>makeDebuggeeValue(value)
<dd>Return the debuggee value that represents value in the debuggee. If value is a primitive, we return it unchanged; if value is an object, we return the <code>Debugger.Object</code> instance representing that object, wrapped appropriately for use in this <code>Debugger.Object</code>'s referent's compartment.

Note that, if value is an object, it need not be one allocated in a debuggee global, nor even a debuggee compartment; it can be any object the debugger wishes to use as a debuggee value.

In Firefox, all cross-compartment object references go through wrappers, meaning that code in different compartments may see different views of the same object. For example, code in the same compartment as the object can access it directly, but code in another compartment can only refer to the object through a wrapper, which may restrict the code's access to the object. This API takes care to ensure that <code>Debugger.Object</code> instances present the same view of the object the debuggee itself would see. Given a <code>Debugger.Object</code> instance d and an object o, the call <code>d.makeDebuggeeValue(o)</code> returns a <code>Debugger.Object</code> instance that presents o as it would be seen by code in d's compartment.

<dt>decompile([pretty])
<dd>If the referent is a function that is debuggee code, return the JavaScript source code for a function definition equivalent to the referent function in its effect and result, as a string. If pretty is present and true, produce indented code with line breaks. If the referent is not a function that is debuggee code, return <code>undefined</code>.

<dt>call(this, argument, ...)
<dd>If the referent is callable, call it with the given this value and argument values, and return a [[#Completion_Values|completion value]] describing how the call completed. This should be a debuggee value, or <code>{ asConstructor: true }</code> to invoke the referent as a constructor, in which case SpiderMonkey provides an appropriate <code>this</code> value itself. Each argument must be a debuggee value. All extant handler methods, breakpoints, watchpoints, and so on remain active during the call. Details of how the call is carried out are given in the description of [[#Debugger.Frame.Debugger|Debugger.Frame.Debugger frames]]. If the referent is not callable, throw a <code>TypeError</code>. This function follows the [[#Invocation_Functions_and_.22debugger.22_Frames|invocation function conventions]].

<dt>apply(this, arguments)
<dd>If the referent is callable, call it with the given this value and the argument values in arguments, and return a [[#Completion_Values|completion value]] describing how the call completed. This should be a debuggee value, or <code>{ asConstructor: true }</code> to invoke function as a constructor, in which case SpiderMonkey provides an appropriate <code>this</code> value itself. Arguments must either be an array (in the debugger) of debuggee values, or <code>null</code> or <code>undefined</code>, which are treated as an empty array. All extant handler methods, breakpoints, watchpoints, and so on remain active during the call. Details of how the call is carried out are given in the description of [[#Debugger.Frame.Debugger|Debugger.Frame.Debugger frames]]. If the referent is not callable, throw a <code>TypeError</code>. This function follows the [[#Invocation_Functions_and_.22debugger.22_Frames|invocation function conventions]].

<dt>evalInGlobal(code)
<dd>If the referent is a global object, evaluate code in that global environment, and return a [[#Completion_Values|completion value]] describing how it completed. Code is a string. All extant handler methods, breakpoints, watchpoints, and so on remain active during the call. This function follows the [[#Invocation_Functions_and_.22debugger.22_Frames|invocation function conventions]]. If the referent is not a global object, throw a <code>TypeError</code> exception.

Code is interpreted as strict mode code when it contains a Use Strict Directive.

If code is not strict mode code, then variable declarations in code affect the referent global object. (In the terms used by the ECMAScript specification, the <code>VariableEnvironment</code> of the execution context for the eval code is the referent.)

<dt>evalInGlobalWithBindings(code, bindings)
<dd>Like <code>evalInGlobal</code>, but evaluate code using the referent as the variable object, but with a lexical environment extended with bindings from the object bindings. For each own enumerable property of bindings named name whose value is value, include a variable in the lexical environment in which code is evaluated named name, whose value is value. Each value must be a debuggee value. (This is not like a <code>with</code> statement: code may access, assign to, and delete the introduced bindings without having any effect on the bindings object.)

This method allows debugger code to introduce temporary bindings that are visible to the given debuggee code and which refer to debugger-held debuggee values, and do so without mutating any existing debuggee environment.

Note that, like <code>evalInGlobal</code>, declarations in the code passed to <code>evalInGlobalWithBindings</code> affect the referent global object, even as code is evaluated with bindings visible. (In the terms used by the ECMAScript specification, the <code>VariableEnvironment</code> of the execution context for the eval code is the referent, and the bindings appear in a new declarative environment, which is the eval code's <code>LexicalEnvironment</code>.)

<dt>asEnvironment()
<dd>If the referent is a global object, return the <code>Debugger.Environment</code> instance representing the referent as a variable environment for evaluating code. If the referent is not a global object, throw a <code>TypeError</code>.

<dt>setObjectWatchpoint(handler) (future plan)
<dd>Set a watchpoint on all the referent's own properties, reporting events by calling handler's methods. Any previous watchpoint handler on this <code>Debugger.Object</code> instance is replaced. If handler is null, the referent is no longer watched. Handler may have the following methods, called under the given circumstances:

<dl>
<dt>add(frame, name, descriptor)
<dd>A property named name has been added to the referent. Descriptor is a property descriptor of the sort accepted by <code>Debugger.Object.prototype.defineProperty</code>, giving the newly added property's attributes.
<dt>delete(frame, name)
<dd>The property named name is about to be deleted from the referent.
<dt>change(frame, name, oldDescriptor, newDescriptor)
<dd>The existing property named name on the referent is being changed from those given by oldDescriptor to those given by newDescriptor. This handler method is only called when attributes of the property other than its value are being changed; if only the value is changing, SpiderMonkey calls the handler's <code>set</code> method.
<dt>set(frame, oldValue, newValue)
<dd>The data property named name of the referent is about to have its value changed from oldValue to newValue.

SpiderMonkey only calls this method on assignments to data properties that will succeed; assignments to un-writable data properties fail without notifying the debugger.
<dt>extensionsPrevented(frame)
<dd>The referent has been made non-extensible, as if by a call to <code>Object.preventExtensions</code>.
</dl>

For all watchpoint handler methods:
<ul>
<li>Handler calls receive the handler object itself as the <code>this</code> value.
<li>The frame argument is the current stack frame, whose code is about to perform the operation on the object being reported.
<li>If the method returns <code>undefined</code>, then SpiderMonkey makes the announced change to the object, and continues execution normally. If the method returns an object:
<ul>
<li>If the object has a <code>superseded</code> property whose value is a true value, then SpiderMonkey does not make the announced change.
<li>If the object has a <code>resume</code> property, its value is taken as a [[#Resumption_Values|resumption value]], indicating how execution should proceed. (However, <code>return</code> resumption values are not supported.)
</ul>
<li>If a given method is absent from handler, then events of that sort are ignored. The watchpoint consults handler's properties each time an event occurs, so adding methods to or removing methods from handler after setting the watchpoint enables or disables reporting of the corresponding events.
<li>Values passed to handler's methods are debuggee values. Descriptors passed to handler's methods are ordinary objects in the debugger's compartment, except for <code>value</code>, <code>get</code>, and <code>set</code> properties in descriptors, which are debuggee values; they are the sort of value expected by <code>Debugger.Object.prototype.defineProperty</code>.
<li>Watchpoint handler calls are cross-compartment, intra-thread calls: the call takes place in the same thread that changed the property, and in handler's method's compartment (typically the same as the debugger's compartment).
</ul>

The new watchpoint belongs to the <code>Debugger</code> instance to which this <code>Debugger.Object</code> instance belongs; disabling the <code>Debugger</code> instance disables this watchpoint.

<dt>clearObjectWatchpoint() (future plan)
<dd>Remove any object watchpoint set on the referent.

<dt>setPropertyWatchpoint(name, handler) (future plan)
<dd>Set a watchpoint on the referent's property named name, reporting events by calling handler's methods. Any previous watchpoint handler on this property for this <code>Debugger.Object</code> instance is replaced. If handler is null, the property is no longer watched. Handler is as described for <code>Debugger.Object.prototype.setObjectWatchpoint</code>, except that it does not receive <code>extensionsPrevented</code> events.

<dt>clearPropertyWatchpoint(name) (future plan)
<dd>Remove any watchpoint set on the referent's property named name.

</dl>

== Debugger.Environment ==

A <code>Debugger.Environment</code> instance represents a lexical environment, associating names with variables. Each <code>Debugger.Frame</code> instance representing a debuggee frame has an associated environment object describing the variables in scope in that frame; and each <code>Debugger.Object</code> instance representing a debuggee function has an environment object representing the environment the function has closed over.

ECMAScript environments form a tree, in which each local environment is parented by its enclosing environment (in ECMAScript terms, its 'outer' environment). We say an environment binds an identifier if that environment itself associates the identifier with a variable, independently of its outer environments. We say an identifier is in scope in an environment if the identifier is bound in that environment or any enclosing environment.

SpiderMonkey creates <code>Debugger.Environment</code> instances as needed as the debugger inspects stack frames and function objects; calling <code>Debugger.Environment</code> as a function or constructor raises a <code>TypeError</code> exception.

SpiderMonkey creates exactly one <code>Debugger.Environment</code> instance for each environment it presents via a given <code>Debugger</code> instance: if the debugger encounters the same environment through two different routes (perhaps two functions have closed over the same environment), SpiderMonkey presents the same <code>Debugger.Environment</code> instance to the debugger each time. This means that the debugger can use the <code>==</code> operator to recognize when two <code>Debugger.Environment</code> instances refer to the same environment in the debuggee, and place its own properties on a <code>Debugger.Environment</code> instance to store metadata about particular environments.

(If more than one <code>Debugger</code> instance is debugging the same code, each <code>Debugger</code> gets a separate <code>Debugger.Environment</code> instance for a given environment. This allows the code using each <code>Debugger</code> instance to place whatever properties it likes on its own <code>Debugger.Object</code> instances, without worrying about interfering with other debuggers.)

<code>Debugger.Environment</code> instances protect their referents from the garbage collector; as long as the <code>Debugger.Environment</code> instance is live, the referent remains live. Garbage collection has no visible effect on <code>Debugger.Environment</code> instances.

=== Accessor Properties of the Debugger.Environment Prototype Object ===

A <code>Debugger.Environment</code> instance inherits the following accessor properties from its prototype:

<dl>
<dt>type
<dd>The type of this environment object, one of the following values:
<ul>
<li>"declarative", indicating that the environment is a declarative environment record. Function calls, calls to <code>eval</code>, <code>let</code> blocks, <code>catch</code> blocks, and the like create declarative environment records.
<li>"object", indicating that the environment's bindings are the properties of an object. The global object and DOM elements appear in the chain of environments via object environments. (Note that <code>with</code> statements have their own environment type.)
<li>"with", indicating that the environment was introduced by a <code>with</code> statement.
</ul>

<dt>parent
<dd>The environment that encloses this one (the "outer" environment, in ECMAScript terminology), or <code>null</code> if this is the outermost environment.

<dt>object
<dd>A <code>Debugger.Object</code> instance referring to the object whose properties this environment reflects. If this is a declarative environment record, this accessor throws a <code>TypeError</code> (since declarative environment records have no such object). Both <code>"object"</code> and <code>"with"</code> environments have <code>object</code> properties that provide the object whose properties they reflect as variable bindings.
</dl>

=== Function Properties of the Debugger.Environment Prototype Object ===

The methods described below may only be called with a <code>this</code> value referring to a <code>Debugger.Environment</code> instance; they may not be used as methods of other kinds of objects.

<dl>
<dt>names()
<dd>Return an array of strings giving the names of the identifiers bound by this environment. The result does not include the names of identifiers bound by enclosing environments.

<dt>getVariable(name)
<dd>Return the value of the variable bound to name in this environment, or <code>undefined</code> if this environment does not bind name. Name must be a string that is a valid ECMAScript identifier name. The result is a debuggee value.

This is not an [[#Invocation_Functions_and_.22debugger.22_Frames|invocation function]]; if this call would cause debuggee code to run (say, because the environment is a <code>"with"</code> environment, and name refers to an accessor property of the <code>with</code> statement's operand), this call throws a [[#The_Debugger.DebuggeeWouldRun_Exception|<code>Debugger.DebuggeeWouldRun</code>]] exception.

<dt>setVariable(name, value)
<dd>Store value as the value of the variable bound to name in this environment, creating the variable if it does not exist. Name must be a string that is a valid ECMAScript identifier name; value must be a debuggee value.

If this call would add a new variable to this environment, but implementation restrictions prevent SpiderMonkey from extending the environment as requested, this call throws an <code>Error</code> exception.

This is not an [[#Invocation_Functions_and_.22debugger.22_Frames|invocation function]]; if this call would cause debuggee code to run, this call throws a [[#The_Debugger.DebuggeeWouldRun_Exception|<code>Debugger.DebuggeeWouldRun</code>]] exception.

<dt>getVariableDescriptor(name)
<dd>Return an property descriptor describing the variable bound to name in this environment, of the sort returned by <code>Debugger.Object.prototype.getOwnPropertyDescriptor</code>. Name must be a string whose value is a valid ECMAScript identifier name.

If this is an <code>"object"</code> or <code>"with"</code> environment record, this simply returns the descriptor for the given property of the environment's object. If this is a declarative environment record, this returns a descriptor reflecting the binding's mutability as the descriptor's <code>writable</code> property, and its deletability as the descriptor's <code>configurable</code> property. All declarative environment record bindings are marked as <code>enumerable</code>. (This isn't great; the semantics of variables in declarative enviroments don't really match those of properties, so
writing code that operates properly on descriptors for either kind may be difficult.)

If there is no variable named name bound in this environment, throw a <code>ReferenceError</code>.

<dt>defineVariable(name, descriptor)
<dd>Create or reconfigure the variable bound to name in this environment according to descriptor. Descriptor is the sort of value returned by <code>getVariableDescriptor</code>. On success, return <code>undefined</code>; on failure, throw an appropriate exception. Name must be a string whose value is a valid ECMAScript identifier name.

If implementation restrictions prevent SpiderMonkey from creating or reconfiguring the variable as requested, this call throws an <code>Error</code> exception.

<dt>find(name)
<dd>Return a reference to the innermost environment, starting with this environment, that binds name. If name is not in scope in this environment, return <code>null</code>. Name must be a string whose value is a valid ECMAScript identifier name.

<dt>eval(code) (future plan)
<dd>Evaluate code in this environment, and return a [[#Completion_Values|completion value]] describing how it completed. Code is a string. All extant handler methods, breakpoints, watchpoints, and so on remain active during the call. This function follows the [[#Invocation_Functions_and_.22debugger.22_Frames|invocation function conventions]].

Code is interpreted as strict mode code when it contains a Use Strict Directive.

If code is not strict mode code, then variable declarations in code affect this environment. (In the terms used by the ECMAScript specification, the <code>VariableEnvironment</code> of the execution context for the eval code is the <code>VariableEnvironment</code> this <code>Debugger.Environment</code> instance represents.) If implementation restrictions prevent SpiderMonkey from extending this environment as requested, this call throws an <code>Error</code> exception.

<dt>evalWithBindings(code, bindings) (future plan)
<dd>Like <code>eval</code>, but evaluate code in this environment, extended with bindings from the object bindings. For each own enumerable property of bindings named name whose value is value, include a variable in the environment in which code is evaluated named name, whose value is value. Each value must be a debuggee value. (This is not like a <code>with</code> statement: code may access, assign to, and delete the introduced bindings without having any effect on the bindings object.)

This method allows debugger code to introduce temporary bindings that are visible to the given debuggee code and which refer to debugger-held debuggee values, and do so without mutating any existing debuggee environment.

Note that, like <code>eval</code>, declarations in the code passed to <code>evalWithBindings</code> affect this environment, even as code is evaluated with bindings visible. (In the terms used by the ECMAScript specification, the <code>VariableEnvironment</code> of the execution context for the eval code is the <code>VariableEnvironment</code> this environment represents, and the bindings appear in a new declarative environment, which is the eval code's <code>LexicalEnvironment</code>.) If implementation restrictions prevent SpiderMonkey from extending this environment as requested, this call throws an <code>Error</code> exception.
</dl>

== Future Work ==

<ul>
<li>Since common optimizations (say, the "null closure" closure representation) make environments that one would expect to be present, given the source code, unavailable at run time, <code>Debugger.Environment</code> should provide ways to reflect what is and is not available.
<li>It may be possible for <code>Debugger.Frame.prototype.environment</code> to return more complete environment chains than <code>Debugger.Object.prototype.environment</code>. This possibility should be documented, along with its effects on environment identity.
<li>The interface should provide clean, predictable ways to observe the effects of garbage collection. For example, perhaps it should provide an interface like [[http://www.cs.indiana.edu/~dyb/pubs/guardians-abstract.html R. Kent Dybvig's guardians]] for observing when objects and scripts become unreachable.
</ul>

User:Jorend/Deterministic hash tables

2012-02-27T21:12:30Z

Jorend: /* Theory */

= Abstract =

A deterministic hash table proposed by Tyler Close was implemented in C++ and its performance was compared to two hash table implementations using open addressing. Speed and memory usage were measured.

'''Speed.''' The Close table implementation was very fast, faster than the open addressing implementations. (It is unclear why; theory suggests it "should" be slower, and measurement confirms that the Close table is doing more memory accesses and more branches. More investigation is needed!)

'''Memory.''' The Close table implementation always allocates more memory than the leanest open addressing implementation. See the Results section for details.

= Background =

Most hash table APIs (including C++'s <code>unordered_map</code>, Java's <code>java.util.HashMap</code>, Python's <code>dict</code>, Ruby's <code>Hash</code>, and many others) allow users to iterate over all the entries in the hash table in an arbitrary order. This exposes the user to an aspect of the library's behavior (the iteration order) that is unspecified and indeed intentionally arbitrary.

<code>Map</code> and <code>Set</code> data structures are proposed for a future version of the ECMAScript programming language. The standard committee would like to specify deterministic behavior if possible. There are several reasons for this:

* There is evidence that some programmers find arbitrary iteration order surprising or confusing at first. [http://stackoverflow.com/questions/2453624/unsort-hashtable][http://stackoverflow.com/questions/1872329/storing-python-dictionary-entries-in-the-order-they-are-pushed][https://groups.google.com/group/comp.lang.python/browse_thread/thread/15f3b4a5cd6221b1/1b6621daf5d78d73][http://bytes.com/topic/c-sharp/answers/439203-hashtable-items-order][http://stackoverflow.com/questions/1419708/how-to-keep-the-order-of-elements-in-hashtable][http://stackoverflow.com/questions/7105540/hashtable-values-reordered]
* Property enumeration order is unspecified in ECMAScript, yet all the major implementations have been forced to converge on insertion order, for compatibility with the Web as it is. There is, therefore, some concern that if TC39 does not specify a deterministic iteration order, “the web will just go and specify it for us”.[https://mail.mozilla.org/pipermail/es-discuss/2012-February/020576.html]
* Hash table iteration order can expose some bits of object hash codes. This imposes some astonishing security concerns on the hashing function implementer. For example, an object's address must not be recoverable from the exposed bits of its hash code. (Revealing object addresses to untrusted ECMAScript code, while not exploitable by itself, would be a bad security bug on the Web.)

Can a data structure retain the performance of traditional, arbitrary-order hash tables while also storing the order in which entries were added, so that iteration order is deterministic?

Tyler Close has developed a deterministic hash table that is structured like this (pseudocode):

struct Entry {
Key key;
Value value;
Entry *chain;
}

class CloseTable {
Entry*[] hashTable; // array of pointers into the data table
Entry[] dataTable;
}

Lookups and inserts proceed much like a bucket-and-chain hash table, but instead of each entry being allocated separately from the heap, they are stored in the <code>dataTable</code> in insertion order.

Removing an entry simply replaces its <code>key</code> with some sentinel while leaving the <code>chain</code> intact.

== Theory ==

'''Memory.''' Every map data structure must store the keys and values. A map with ''N'' entries must use at least ''NE'' memory, where ''E'' is the size of a key-value pair (we assume the data can’t be compressed).

In the following discussion we neglect the effect of deletions, which can cause both kinds of table to have extra memory that isn't in use at a given moment.

An open addressing hash table has additional overhead depending on the fill factor. <code>OpenTable</code> in particular has a maximum fill factor ''F''=3/4. When it becomes more than 3/4 full, it doubles in size, becoming just over 3/8 full. The amount of overhead in an <code>OpenTable</code> is ''(1/f)NE'', where ''f'' is the actual current fill ratio of the table and ''F/2 < f ≤ F''.

A Close table has three sources of overhead: the entire <code>hashTable</code>, the <code>chain</code> pointers in the <code>dataTable</code>, and the unused portion of the <code>dataTable</code>. In <code>CloseTable</code>, the <code>chain</code> pointer causes each entry to require ''(3/2)E'' memory rather than ''E''. The <code>dataTable</code> doubles in size when it becomes completely full, so its size is ''(3/2)(1/u)NE'' where ''u'' is the proportion of the <code>dataTable</code> that is in use and ''1/2 hashTable</code> is always 1/16 the size of the <code>dataTable</code> (1/8 on 64-bit platforms), so the total size of both tables is ''(1+1/16)(3/2)(1/u)NE'' (substitute 1/8 on 64-bit platforms).

For back-of-envelope purposes, then, ''f'' may be expected to be about ''3F/4'' (halfway between F/2 and F) and ''u'' about 3/4 on average; plugging these numbers in, we expect an <code>OpenTable</code> to use about (1/(3F/4)) = 1.78×''NE'', and a <code>CloseTable</code> about 2.13×''NE'' (2.25×''NE'' on 64-bit), on average. This would mean that the <code>CloseTable</code> would be 20% larger on average (27% larger on 64-bit). However, see the Results section for a picture of how the two implementations compare in practice.

'''Lookup speed.''' The <code>get</code>, <code>has</code>, <code>set</code>, and <code>delete</code> operations all start with a lookup. We will quantify lookup speed in terms of how many memory locations must be accessed. To simulate locality effects, we treat multiple reads from a single entry, or from the table object, as a single read.

In an open addressing hash table with fill factor ''f'', an unsuccessful lookup performs about ''1/(1-f)'' probes.[https://en.wikipedia.org/wiki/Hash_table#Performance_analysis] In an <code>OpenTable</code>, at worst ''f=F=3/4'' and so an unsuccessful lookup performs 4 probes on average. In the usual case, ''f=3F/4=9/16'', so about 2.3 probes on average. A successful lookup performs half as many probes on average. Before probing the table, the lookup must access the <code>OpenTable</code> struct itself, so the final numbers are as shown in the table: 5 reads, 3.3 reads, etc.

A Close table uses direct chaining. Each lookup must read first the <code>CloseTable</code> object itself, and next the <code>hashTable</code>. Then, for an unsuccessful lookup, the whole chain is walked; the expected length of the chain is simply the number of keys in the table divided by the number of hash buckets. For a <code>CloseTable</code>, this quotient is at most 8/3 and typically 2. A successful lookup would perform about half as many probes, if keys were distributed evenly, but instead they are distributed randomly, making successful lookups slower; by simulation, I found the expected number of probes is 2.3 under full load and 2 under typical load.

<table class="data">
<tr>
<th></th>
<th colspan=2>Expected cost of unsuccessful lookup (miss)</th>
<th colspan=2>Expected cost of successful lookup (hit)</th>
</tr>
<tr>
<th>Data structure</th>
<th>Maximum load</th>
<th>Typical load</th>
<th>Maximum load</th>
<th>Typical load</th>
</tr>
<tr>
<td><code>OpenTable</code>
<td>5
<td>3.3
<td>3
<td>2.2
</tr>
<tr>
<td><code>CloseTable</code>
<td>4.7
<td>4
<td>4.3
<td>4
</tr>
</table>

'''Note:''' This analysis does not explain the lookup speed observed in practice. See the Results section.

= Method =

The code I used to make these pictures is available at: https://github.com/jorendorff/dht

The graphs below show data collected on a MacBook Pro, using g++-apple-4.2 and a 64-bit build. The results from running the test on a 32-bit Windows build were basically qualitatively the same. CloseTable performance was even better on Windows, for most tests; however, on LookupHitTest, OpenTable achieved almost equal speed.

The project contains two complete hash map implementations: OpenTable and CloseTable. A third implementation, DenseTable, is a thin wrapper around the <code>dense_hash_map</code> type from [https://code.google.com/p/sparsehash/ Sparsehash]. The three classes have the same API and were all benchmarked using the same templates (in hashbench.cpp).

Hash table implementation design notes:

* The API was designed to match the [http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets proposal for ECMAScript Map objects] as of February 2012.

* The Key and Value types are <code>uint64_t</code> because ECMAScript values are 64 bits in the implementation I'm most familiar with.

* OpenTable and CloseTable are meant to be as fast and as memory-efficient as possible. Pretty much everything that can be omitted was omitted. For example, the hashing function is trivial: ''hash(key) = key'', and neither OpenTable nor CloseTable further munges the hashcode before using it as a table index. Rationale: Making each implementation as fast as possible should highlight any performance difference between OpenTable and CloseTable, which is the purpose of the exercise. Using a more sophisticated hashing function would slow down both implementations, reducing the observed difference between the two techniques.

* DenseTable is provided as a baseline. (It's nice to have some realistic numbers in the graphs too.)

* dense_hash_map and OpenTable both implement straightforward hash tables with open addressing. The main difference between the two is one of tuning. dense_hash_map has a maximum load factor of 0.5. OpenTable has a maximum load factor of 0.75, which causes it to use about half as much memory most of the time.

* The purpose of the typedefs KeyArg and ValueArg is to make it possible to switch the API from pass-by-value to pass-by-reference by editing just a couple of lines of code. (I tried this. Pass-by-reference is no faster on 64-bit machines.)

* CloseTable attempts to allocate chunks of memory with sizes that are near powers of 2. This is to avoid wasting space when used with size-class-based malloc implementations.

* A Close table can trade some speed for compactness, but it seems to be a bad bargain:
** The load factor is adjustable. (The hash table size must remain at a power of two, but the data vector can have non-power-of-2 sizes.) However, increasing the load factor directly affects LookupMiss speed.
** An implementation could grow the data array by less than doubling it each time. I tried this. Insert speed suffered; lookup speed was unaffected; but the modified CloseTable still used more memory than OpenTable.

* <code>dense_hash_map</code> never shrinks the table unless you explicitly ask it to. <code>DenseTable::remove()</code> periodically shrinks, because otherwise, the performance on LookupAfterDeleteTest is pathologically bad.

Benchmark design notes:

* The benchmark is pure C++, rather than a Map/Set implementation embedded in an existing ES implementation, in order to make the results as stable as possible, to avoid biasing the results to a particular ES implementation, to encourage contributors, and to focus on the performance differences in the hash table implementations by eliminating all other performance effects as much as possible.

* The program runs each benchmark many different times in order to produce enough numbers that noise is visually obvious in the resulting graph. (Most of the speed graphs are nice and smooth.)

= Results =

== Memory usage ==

[[Image:jorendorff-dht-figure-1.png]]

All three implementations double the size of the table whenever it gets too full. On a log-log plot, this shows as stair-steps of a constant height. The slope of each staircase is 1, indicating linear growth.

Both OpenTable and CloseTable are much more memory-efficient than DenseTable, because <code>dense_hash_map</code> is tuned for fast lookups at all costs.

For any ''N'' > 5, a CloseTable with ''N'' entries allocates '''either 1.0625x or 2.125x as much memory''' as an OpenTable with ''N'' entries (1.125x or 2.25x as much memory on 64-bit systems). Both tables double in size at certain thresholds, and the thresholds for CloseTable are lower than those for OpenTable. That is, as a CloseTable is populated, it doubles in size sooner than the corresponding OpenTable. The factors determining this behavior are (1) the fact that CloseTable entries are 50% larger, and it therefore takes fewer of them to fill up a power-of-two-sized allocation; and (2) the value of <code>OpenTable::max_fill_factor()</code>.

It is tempting to reduce this complicated picture to a single number, and write that CloseTables are, for example, 20% larger. Or 30%. But such a number would not be easily justified mathematically: the ratio does not converge as the number of entries increases.

[[Image:jorendorff-dht-figure-2.png]]

DenseTable and OpenTable must initialize the entire table each time they resize. CloseTable also allocates large chunks of memory, but like a <code>vector</code>, it does not need to write to that memory until there is data that needs to be stored there.

This means that for a huge Map with no delete operations, a Close table could use more virtual memory but less physical memory than its open addressing counterparts. This will not be the only use case that stresses memory usage, though. Applications may also create many small tables and may delete entries from large tables.

== Insertion speed ==

[[Image:jorendorff-dht-InsertSmallTest-speed.png]]

This measures the time required to fill a table to about 100 entries, repeatedly. (The “1e7” on the axes indicates that the numbers are in tens of millions: the Close table is doing about 60 million inserts per second on this machine.)

This graph and the following ones show speed, so '''higher is better'''.

Ideally all these graphs would show three straight horizontal lines, indicating that all three implementations scale beautifully to large work loads. And indeed this seems to be the case, mostly.

[[Image:jorendorff-dht-InsertLargeTest-speed.png]]

This test measures the time required to fill a single gigantic table.

The jagged shape of this graph is robust. It reflects the fact that the table doubles in size as it grows, and rehashing is a significant part of the expense of populating a huge table.

== Lookup speed ==

[[Image:jorendorff-dht-LookupHitTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where ''k'' is the key of an existing entry in the table.

[[Image:jorendorff-dht-LookupMissTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where the key ''k'' is not found in the table.

In an OpenTable, lookups that miss are slower than lookups that hit ''when there is at least one collision''. This is because we keep probing the hash table until we find an empty entry.

DenseTable is only slightly slower for misses, perhaps because more lookups have zero collisions. (?)

== Deletion speed ==

[[Image:jorendorff-dht-WorklistTest-speed.png]]

This test creates a table with 700 entries, then measures the speed of alternately adding an entry and deleting the oldest remaining entry from the table. Entries are therefore removed in FIFO order. Each “operation” here includes both an insert and a delete.

The CloseTable stores the entries in insertion order, so this test gets extremely good memory locality. The effect is even more pronounced in a 32-bit build.

[[Image:jorendorff-dht-DeleteTest-speed.png]]

This test measures the speed of deleting all entries from a very large table.

The numbers for dense_hash_map are jagged because <code>DenseMap</code> shrinks the table at certain threshold sizes as entries are deleted, and shrinking the table is expensive.

The apparent randomness of the OpenTable and CloseTable numbers is reproducible and unexplained.

[[Image:jorendorff-dht-LookupAfterDeleteTest-speed.png]]

This test measures the performance of lookups, mostly misses, in a table that was filled to size 50000, then reduced to size 195 by deleting most of the entries.

The results here are sensitive to the two sizes, which are totally arbitrary choices. A less arbitrary replacement for this test would be welcome.

User:Jorend/Deterministic hash tables

2012-02-27T21:10:14Z

Jorend: /* Theory */ remove extra table, it doesn't really help

= Abstract =

A deterministic hash table proposed by Tyler Close was implemented in C++ and its performance was compared to two hash table implementations using open addressing. Speed and memory usage were measured.

'''Speed.''' The Close table implementation was very fast, faster than the open addressing implementations. (It is unclear why; theory suggests it "should" be slower, and measurement confirms that the Close table is doing more memory accesses and more branches. More investigation is needed!)

'''Memory.''' The Close table implementation always allocates more memory than the leanest open addressing implementation. See the Results section for details.

= Background =

Most hash table APIs (including C++'s <code>unordered_map</code>, Java's <code>java.util.HashMap</code>, Python's <code>dict</code>, Ruby's <code>Hash</code>, and many others) allow users to iterate over all the entries in the hash table in an arbitrary order. This exposes the user to an aspect of the library's behavior (the iteration order) that is unspecified and indeed intentionally arbitrary.

<code>Map</code> and <code>Set</code> data structures are proposed for a future version of the ECMAScript programming language. The standard committee would like to specify deterministic behavior if possible. There are several reasons for this:

* There is evidence that some programmers find arbitrary iteration order surprising or confusing at first. [http://stackoverflow.com/questions/2453624/unsort-hashtable][http://stackoverflow.com/questions/1872329/storing-python-dictionary-entries-in-the-order-they-are-pushed][https://groups.google.com/group/comp.lang.python/browse_thread/thread/15f3b4a5cd6221b1/1b6621daf5d78d73][http://bytes.com/topic/c-sharp/answers/439203-hashtable-items-order][http://stackoverflow.com/questions/1419708/how-to-keep-the-order-of-elements-in-hashtable][http://stackoverflow.com/questions/7105540/hashtable-values-reordered]
* Property enumeration order is unspecified in ECMAScript, yet all the major implementations have been forced to converge on insertion order, for compatibility with the Web as it is. There is, therefore, some concern that if TC39 does not specify a deterministic iteration order, “the web will just go and specify it for us”.[https://mail.mozilla.org/pipermail/es-discuss/2012-February/020576.html]
* Hash table iteration order can expose some bits of object hash codes. This imposes some astonishing security concerns on the hashing function implementer. For example, an object's address must not be recoverable from the exposed bits of its hash code. (Revealing object addresses to untrusted ECMAScript code, while not exploitable by itself, would be a bad security bug on the Web.)

Can a data structure retain the performance of traditional, arbitrary-order hash tables while also storing the order in which entries were added, so that iteration order is deterministic?

Tyler Close has developed a deterministic hash table that is structured like this (pseudocode):

struct Entry {
Key key;
Value value;
Entry *chain;
}

class CloseTable {
Entry*[] hashTable; // array of pointers into the data table
Entry[] dataTable;
}

Lookups and inserts proceed much like a bucket-and-chain hash table, but instead of each entry being allocated separately from the heap, they are stored in the <code>dataTable</code> in insertion order.

Removing an entry simply replaces its <code>key</code> with some sentinel while leaving the <code>chain</code> intact.

== Theory ==

'''Memory.''' Every map data structure must store the keys and values. A map with ''N'' entries must use at least ''NE'' memory, where ''E'' is the size of a key-value pair (we assume the data can’t be compressed).

In the following discussion we neglect the effect of deletions, which can cause both kinds of table to have extra memory that isn't in use at a given moment.

An open addressing hash table has additional overhead depending on the fill factor. <code>OpenTable</code> in particular has a maximum fill factor ''F''=3/4. When it becomes more than 3/4 full, it doubles in size, becoming just over 3/8 full. The amount of overhead in an <code>OpenTable</code> is ''(1/f)NE'', where ''f'' is the actual current fill ratio of the table and ''F/2 < f ≤ F''.

A Close table has three sources of overhead: the entire <code>hashTable</code>, the <code>chain</code> pointers in the <code>dataTable</code>, and the unused portion of the <code>dataTable</code>. In <code>CloseTable</code>, the <code>chain</code> pointer causes each entry to require ''(3/2)E'' memory rather than ''E''. The <code>dataTable</code> doubles in size when it becomes completely full, so its size is ''(3/2)(1/u)NE'' where ''u'' is the proportion of the <code>dataTable</code> that is in use and ''1/2 hashTable</code> is always 1/16 the size of the <code>dataTable</code> (1/8 on 64-bit platforms), so the total size of both tables is ''(1+1/16)(3/2)(1/u)NE'' (substitute 1/8 on 64-bit platforms).

For back-of-envelope purposes, then, ''f'' may be expected to be about ''3F/4'' (halfway between F/2 and F) and ''u'' about 3/4 on average; plugging these numbers in, we expect an <code>OpenTable</code> to use about (1/(3F/4)) = 1.78×''NE'', and a <code>CloseTable</code> about 2.13×''NE'' (2.25×''NE'' on 64-bit), on average. This would mean that the <code>CloseTable</code> would be 20% larger on average (27% larger on 64-bit). However, see the Results section for a picture of how the two implementations compare in practice.

'''Lookup speed.''' The <code>get</code>, <code>has</code>, <code>set</code>, and <code>delete</code> operations all start with a lookup. We will quantify lookup speed in terms of how many memory locations must be accessed. To simulate locality effects, we treat multiple reads from a single entry, or from the table object, as a single read.

In an open addressing hash table with fill factor ''f'', an unsuccessful lookup performs about ''1/(1-f)'' probes.[https://en.wikipedia.org/wiki/Hash_table#Performance_analysis] In an <code>OpenTable</code>, at worst ''f=F=3/4'' and so an unsuccessful lookup performs 4 probes on average. In the usual case, ''f=3F/4=9/16'', so about 2.3 probes on average. A successful lookup performs half as many probes on average. Before probing the table, the lookup must access the <code>OpenTable</code> struct itself, so the final numbers are as shown in the table: 5 reads, 3.3 reads, etc.

A Close table uses direct chaining. Each lookup must read first the <code>CloseTable</code> object itself, and next the <code>hashTable</code>. Then, for an unsuccessful lookup, the whole chain is walked; the expected length of the chain is simply the number of keys in the table divided by the number of hash buckets. For a <code>CloseTable</code>, this quotient is at most 8/3 and typically 2. A successful lookup would perform about half as many probes, if keys were distributed evenly, but instead they are distributed randomly, making successful lookups slower; by simulation, I found the expected number of probes is 2.3 under full load and 2 under typical load.

<table class="data">
<tr>
<th></th>
<th colspan=2>Expected cost of unsuccessful lookup (miss)</th>
<th colspan=2>Expected cost of successful lookup (hit)</th>
</tr>
<tr>
<th>Data structure</th>
<th>Maximum load</th>
<th>Typical load</th>
<th>Maximum load</th>
<th>Typical load</th>
</tr>
<tr>
<td><code>OpenTable</code>
<td>5
<td>3.3
<td>3
<td>2.2
</tr>
<tr>
<td><code>CloseTable</code>
<td>4.7
<td>4
<td>4.3
<td>4
</tr>
</table>

= Method =

The code I used to make these pictures is available at: https://github.com/jorendorff/dht

The graphs below show data collected on a MacBook Pro, using g++-apple-4.2 and a 64-bit build. The results from running the test on a 32-bit Windows build were basically qualitatively the same. CloseTable performance was even better on Windows, for most tests; however, on LookupHitTest, OpenTable achieved almost equal speed.

The project contains two complete hash map implementations: OpenTable and CloseTable. A third implementation, DenseTable, is a thin wrapper around the <code>dense_hash_map</code> type from [https://code.google.com/p/sparsehash/ Sparsehash]. The three classes have the same API and were all benchmarked using the same templates (in hashbench.cpp).

Hash table implementation design notes:

* The API was designed to match the [http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets proposal for ECMAScript Map objects] as of February 2012.

* The Key and Value types are <code>uint64_t</code> because ECMAScript values are 64 bits in the implementation I'm most familiar with.

* OpenTable and CloseTable are meant to be as fast and as memory-efficient as possible. Pretty much everything that can be omitted was omitted. For example, the hashing function is trivial: ''hash(key) = key'', and neither OpenTable nor CloseTable further munges the hashcode before using it as a table index. Rationale: Making each implementation as fast as possible should highlight any performance difference between OpenTable and CloseTable, which is the purpose of the exercise. Using a more sophisticated hashing function would slow down both implementations, reducing the observed difference between the two techniques.

* DenseTable is provided as a baseline. (It's nice to have some realistic numbers in the graphs too.)

* dense_hash_map and OpenTable both implement straightforward hash tables with open addressing. The main difference between the two is one of tuning. dense_hash_map has a maximum load factor of 0.5. OpenTable has a maximum load factor of 0.75, which causes it to use about half as much memory most of the time.

* The purpose of the typedefs KeyArg and ValueArg is to make it possible to switch the API from pass-by-value to pass-by-reference by editing just a couple of lines of code. (I tried this. Pass-by-reference is no faster on 64-bit machines.)

* CloseTable attempts to allocate chunks of memory with sizes that are near powers of 2. This is to avoid wasting space when used with size-class-based malloc implementations.

* A Close table can trade some speed for compactness, but it seems to be a bad bargain:
** The load factor is adjustable. (The hash table size must remain at a power of two, but the data vector can have non-power-of-2 sizes.) However, increasing the load factor directly affects LookupMiss speed.
** An implementation could grow the data array by less than doubling it each time. I tried this. Insert speed suffered; lookup speed was unaffected; but the modified CloseTable still used more memory than OpenTable.

* <code>dense_hash_map</code> never shrinks the table unless you explicitly ask it to. <code>DenseTable::remove()</code> periodically shrinks, because otherwise, the performance on LookupAfterDeleteTest is pathologically bad.

Benchmark design notes:

* The benchmark is pure C++, rather than a Map/Set implementation embedded in an existing ES implementation, in order to make the results as stable as possible, to avoid biasing the results to a particular ES implementation, to encourage contributors, and to focus on the performance differences in the hash table implementations by eliminating all other performance effects as much as possible.

* The program runs each benchmark many different times in order to produce enough numbers that noise is visually obvious in the resulting graph. (Most of the speed graphs are nice and smooth.)

= Results =

== Memory usage ==

[[Image:jorendorff-dht-figure-1.png]]

All three implementations double the size of the table whenever it gets too full. On a log-log plot, this shows as stair-steps of a constant height. The slope of each staircase is 1, indicating linear growth.

Both OpenTable and CloseTable are much more memory-efficient than DenseTable, because <code>dense_hash_map</code> is tuned for fast lookups at all costs.

For any ''N'' > 5, a CloseTable with ''N'' entries allocates '''either 1.0625x or 2.125x as much memory''' as an OpenTable with ''N'' entries (1.125x or 2.25x as much memory on 64-bit systems). Both tables double in size at certain thresholds, and the thresholds for CloseTable are lower than those for OpenTable. That is, as a CloseTable is populated, it doubles in size sooner than the corresponding OpenTable. The factors determining this behavior are (1) the fact that CloseTable entries are 50% larger, and it therefore takes fewer of them to fill up a power-of-two-sized allocation; and (2) the value of <code>OpenTable::max_fill_factor()</code>.

It is tempting to reduce this complicated picture to a single number, and write that CloseTables are, for example, 20% larger. Or 30%. But such a number would not be easily justified mathematically: the ratio does not converge as the number of entries increases.

[[Image:jorendorff-dht-figure-2.png]]

DenseTable and OpenTable must initialize the entire table each time they resize. CloseTable also allocates large chunks of memory, but like a <code>vector</code>, it does not need to write to that memory until there is data that needs to be stored there.

This means that for a huge Map with no delete operations, a Close table could use more virtual memory but less physical memory than its open addressing counterparts. This will not be the only use case that stresses memory usage, though. Applications may also create many small tables and may delete entries from large tables.

== Insertion speed ==

[[Image:jorendorff-dht-InsertSmallTest-speed.png]]

This measures the time required to fill a table to about 100 entries, repeatedly. (The “1e7” on the axes indicates that the numbers are in tens of millions: the Close table is doing about 60 million inserts per second on this machine.)

This graph and the following ones show speed, so '''higher is better'''.

Ideally all these graphs would show three straight horizontal lines, indicating that all three implementations scale beautifully to large work loads. And indeed this seems to be the case, mostly.

[[Image:jorendorff-dht-InsertLargeTest-speed.png]]

This test measures the time required to fill a single gigantic table.

The jagged shape of this graph is robust. It reflects the fact that the table doubles in size as it grows, and rehashing is a significant part of the expense of populating a huge table.

== Lookup speed ==

[[Image:jorendorff-dht-LookupHitTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where ''k'' is the key of an existing entry in the table.

[[Image:jorendorff-dht-LookupMissTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where the key ''k'' is not found in the table.

In an OpenTable, lookups that miss are slower than lookups that hit ''when there is at least one collision''. This is because we keep probing the hash table until we find an empty entry.

DenseTable is only slightly slower for misses, perhaps because more lookups have zero collisions. (?)

== Deletion speed ==

[[Image:jorendorff-dht-WorklistTest-speed.png]]

This test creates a table with 700 entries, then measures the speed of alternately adding an entry and deleting the oldest remaining entry from the table. Entries are therefore removed in FIFO order. Each “operation” here includes both an insert and a delete.

The CloseTable stores the entries in insertion order, so this test gets extremely good memory locality. The effect is even more pronounced in a 32-bit build.

[[Image:jorendorff-dht-DeleteTest-speed.png]]

This test measures the speed of deleting all entries from a very large table.

The numbers for dense_hash_map are jagged because <code>DenseMap</code> shrinks the table at certain threshold sizes as entries are deleted, and shrinking the table is expensive.

The apparent randomness of the OpenTable and CloseTable numbers is reproducible and unexplained.

[[Image:jorendorff-dht-LookupAfterDeleteTest-speed.png]]

This test measures the performance of lookups, mostly misses, in a table that was filled to size 50000, then reduced to size 195 by deleting most of the entries.

The results here are sensitive to the two sizes, which are totally arbitrary choices. A less arbitrary replacement for this test would be welcome.

User:Jorend/Deterministic hash tables

2012-02-27T21:07:06Z

Jorend: /* Theory */

= Abstract =

A deterministic hash table proposed by Tyler Close was implemented in C++ and its performance was compared to two hash table implementations using open addressing. Speed and memory usage were measured.

'''Speed.''' The Close table implementation was very fast, faster than the open addressing implementations. (It is unclear why; theory suggests it "should" be slower, and measurement confirms that the Close table is doing more memory accesses and more branches. More investigation is needed!)

'''Memory.''' The Close table implementation always allocates more memory than the leanest open addressing implementation. See the Results section for details.

= Background =

Most hash table APIs (including C++'s <code>unordered_map</code>, Java's <code>java.util.HashMap</code>, Python's <code>dict</code>, Ruby's <code>Hash</code>, and many others) allow users to iterate over all the entries in the hash table in an arbitrary order. This exposes the user to an aspect of the library's behavior (the iteration order) that is unspecified and indeed intentionally arbitrary.

<code>Map</code> and <code>Set</code> data structures are proposed for a future version of the ECMAScript programming language. The standard committee would like to specify deterministic behavior if possible. There are several reasons for this:

* There is evidence that some programmers find arbitrary iteration order surprising or confusing at first. [http://stackoverflow.com/questions/2453624/unsort-hashtable][http://stackoverflow.com/questions/1872329/storing-python-dictionary-entries-in-the-order-they-are-pushed][https://groups.google.com/group/comp.lang.python/browse_thread/thread/15f3b4a5cd6221b1/1b6621daf5d78d73][http://bytes.com/topic/c-sharp/answers/439203-hashtable-items-order][http://stackoverflow.com/questions/1419708/how-to-keep-the-order-of-elements-in-hashtable][http://stackoverflow.com/questions/7105540/hashtable-values-reordered]
* Property enumeration order is unspecified in ECMAScript, yet all the major implementations have been forced to converge on insertion order, for compatibility with the Web as it is. There is, therefore, some concern that if TC39 does not specify a deterministic iteration order, “the web will just go and specify it for us”.[https://mail.mozilla.org/pipermail/es-discuss/2012-February/020576.html]
* Hash table iteration order can expose some bits of object hash codes. This imposes some astonishing security concerns on the hashing function implementer. For example, an object's address must not be recoverable from the exposed bits of its hash code. (Revealing object addresses to untrusted ECMAScript code, while not exploitable by itself, would be a bad security bug on the Web.)

Can a data structure retain the performance of traditional, arbitrary-order hash tables while also storing the order in which entries were added, so that iteration order is deterministic?

Tyler Close has developed a deterministic hash table that is structured like this (pseudocode):

struct Entry {
Key key;
Value value;
Entry *chain;
}

class CloseTable {
Entry*[] hashTable; // array of pointers into the data table
Entry[] dataTable;
}

Lookups and inserts proceed much like a bucket-and-chain hash table, but instead of each entry being allocated separately from the heap, they are stored in the <code>dataTable</code> in insertion order.

Removing an entry simply replaces its <code>key</code> with some sentinel while leaving the <code>chain</code> intact.

== Theory ==

'''Memory.''' Every map data structure must store the keys and values. A map with ''N'' entries must use at least ''NE'' memory, where ''E'' is the size of a key-value pair (we assume the data can’t be compressed).

In the following discussion we neglect the effect of deletions, which can cause both kinds of table to have extra memory that isn't in use at a given moment.

An open addressing hash table has additional overhead depending on the fill factor. <code>OpenTable</code> in particular has a maximum fill factor ''F''=3/4. When it becomes more than 3/4 full, it doubles in size, becoming just over 3/8 full. The amount of overhead in an <code>OpenTable</code> is ''(1/f)NE'', where ''f'' is the actual current fill ratio of the table and ''F/2 < f ≤ F''.

A Close table has three sources of overhead: the entire <code>hashTable</code>, the <code>chain</code> pointers in the <code>dataTable</code>, and the unused portion of the <code>dataTable</code>. In <code>CloseTable</code>, the <code>chain</code> pointer causes each entry to require ''(3/2)E'' memory rather than ''E''. The <code>dataTable</code> doubles in size when it becomes completely full, so its size is ''(3/2)(1/u)NE'' where ''u'' is the proportion of the <code>dataTable</code> that is in use and ''1/2 hashTable</code> is always 1/16 the size of the <code>dataTable</code> (1/8 on 64-bit platforms), so the total size of both tables is ''(1+1/16)(3/2)(1/u)NE'' (substitute 1/8 on 64-bit platforms).

For back-of-envelope purposes, then, ''f'' may be expected to be about ''3F/4'' (halfway between F/2 and F) and ''u'' about 3/4 on average; plugging these numbers in, we expect an <code>OpenTable</code> to use about (1/(3F/4)) = 1.78×''NE'', and a <code>CloseTable</code> about 2.13×''NE'' (2.25×''NE'' on 64-bit), on average. This would mean that the <code>CloseTable</code> would be 20% larger on average (27% larger on 64-bit). However, see the Results section for a picture of how the two implementations compare in practice.

'''Speed.''' We consider the speed of lookups only. The <code>get</code>, <code>has</code>, <code>set</code>, and <code>delete</code> operations all start with a lookup. We will quantify the speed of lookups in terms of how many memory locations must be accessed. To simulate locality effects, we treat multiple reads from a single entry, or from the table object, as a single read.

<table class="data">
<tr>
<th colspan=3>Number of collisions</th>
<td>      0      </td>
<td>      1      </td>
<td>      2      </td>
</tr>
<tr>
<th rowspan=4>Number of reads</th>
<th rowspan=2>Unsuccessful lookup (miss)</th>
<th><code>OpenTable</code></th>
<td>2</td>
<td>3</td>
<td>4</td>
</tr>
<tr>
<th><code>CloseTable</code></th>
<td>2</td>
<td>3</td>
<td>4</td>
</tr>
<tr>
<th rowspan=2>Successful lookup (hit)</th>
<th><code>OpenTable</code></th>
<td>2</td>
<td>2 to 3</td>
<td>2 to 4</td>
</tr>
<tr>
<th><code>CloseTable</code></th>
<td>3</td>
<td>3 to 4</td>
<td>3 to 5</td>
</tr>
</table>

In an open addressing hash table with fill factor ''f'', an unsuccessful lookup performs about ''1/(1-f)'' probes.[https://en.wikipedia.org/wiki/Hash_table#Performance_analysis] In an <code>OpenTable</code>, at worst ''f=F=3/4'' and so an unsuccessful lookup performs 4 probes on average. In the usual case, ''f=3F/4=9/16'', so about 2.3 probes on average. A successful lookup performs half as many probes on average. Before probing the table, the lookup must access the <code>OpenTable</code> struct itself, so the final numbers are as shown in the table: 5 reads, 3.3 reads, etc.

A Close table uses direct chaining. Each lookup must read first the <code>CloseTable</code> object itself, and next the <code>hashTable</code>. Then, for an unsuccessful lookup, the whole chain is walked; the expected length of the chain is simply the number of keys in the table divided by the number of hash buckets. For a <code>CloseTable</code>, this quotient is at most 8/3 and typically 2. A successful lookup would perform about half as many probes, if keys were distributed evenly, but instead they are distributed randomly, making successful lookups slower; by simulation, I found the expected number of probes is 2.3 under full load and 2 under typical load.

<table class="data">
<tr>
<th></th>
<th colspan=2>Expected cost of unsuccessful lookup (miss)</th>
<th colspan=2>Expected cost of successful lookup (hit)</th>
</tr>
<tr>
<th>Data structure</th>
<th>Maximum load</th>
<th>Typical load</th>
<th>Maximum load</th>
<th>Typical load</th>
</tr>
<tr>
<td><code>OpenTable</code>
<td>5
<td>3.3
<td>3
<td>2.2
</tr>
<tr>
<td><code>CloseTable</code>
<td>4.7
<td>4
<td>4.3
<td>4
</tr>
</table>

= Method =

The code I used to make these pictures is available at: https://github.com/jorendorff/dht

The graphs below show data collected on a MacBook Pro, using g++-apple-4.2 and a 64-bit build. The results from running the test on a 32-bit Windows build were basically qualitatively the same. CloseTable performance was even better on Windows, for most tests; however, on LookupHitTest, OpenTable achieved almost equal speed.

The project contains two complete hash map implementations: OpenTable and CloseTable. A third implementation, DenseTable, is a thin wrapper around the <code>dense_hash_map</code> type from [https://code.google.com/p/sparsehash/ Sparsehash]. The three classes have the same API and were all benchmarked using the same templates (in hashbench.cpp).

Hash table implementation design notes:

* The API was designed to match the [http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets proposal for ECMAScript Map objects] as of February 2012.

* The Key and Value types are <code>uint64_t</code> because ECMAScript values are 64 bits in the implementation I'm most familiar with.

* OpenTable and CloseTable are meant to be as fast and as memory-efficient as possible. Pretty much everything that can be omitted was omitted. For example, the hashing function is trivial: ''hash(key) = key'', and neither OpenTable nor CloseTable further munges the hashcode before using it as a table index. Rationale: Making each implementation as fast as possible should highlight any performance difference between OpenTable and CloseTable, which is the purpose of the exercise. Using a more sophisticated hashing function would slow down both implementations, reducing the observed difference between the two techniques.

* DenseTable is provided as a baseline. (It's nice to have some realistic numbers in the graphs too.)

* dense_hash_map and OpenTable both implement straightforward hash tables with open addressing. The main difference between the two is one of tuning. dense_hash_map has a maximum load factor of 0.5. OpenTable has a maximum load factor of 0.75, which causes it to use about half as much memory most of the time.

* The purpose of the typedefs KeyArg and ValueArg is to make it possible to switch the API from pass-by-value to pass-by-reference by editing just a couple of lines of code. (I tried this. Pass-by-reference is no faster on 64-bit machines.)

* CloseTable attempts to allocate chunks of memory with sizes that are near powers of 2. This is to avoid wasting space when used with size-class-based malloc implementations.

* A Close table can trade some speed for compactness, but it seems to be a bad bargain:
** The load factor is adjustable. (The hash table size must remain at a power of two, but the data vector can have non-power-of-2 sizes.) However, increasing the load factor directly affects LookupMiss speed.
** An implementation could grow the data array by less than doubling it each time. I tried this. Insert speed suffered; lookup speed was unaffected; but the modified CloseTable still used more memory than OpenTable.

* <code>dense_hash_map</code> never shrinks the table unless you explicitly ask it to. <code>DenseTable::remove()</code> periodically shrinks, because otherwise, the performance on LookupAfterDeleteTest is pathologically bad.

Benchmark design notes:

* The benchmark is pure C++, rather than a Map/Set implementation embedded in an existing ES implementation, in order to make the results as stable as possible, to avoid biasing the results to a particular ES implementation, to encourage contributors, and to focus on the performance differences in the hash table implementations by eliminating all other performance effects as much as possible.

* The program runs each benchmark many different times in order to produce enough numbers that noise is visually obvious in the resulting graph. (Most of the speed graphs are nice and smooth.)

= Results =

== Memory usage ==

[[Image:jorendorff-dht-figure-1.png]]

All three implementations double the size of the table whenever it gets too full. On a log-log plot, this shows as stair-steps of a constant height. The slope of each staircase is 1, indicating linear growth.

Both OpenTable and CloseTable are much more memory-efficient than DenseTable, because <code>dense_hash_map</code> is tuned for fast lookups at all costs.

For any ''N'' > 5, a CloseTable with ''N'' entries allocates '''either 1.0625x or 2.125x as much memory''' as an OpenTable with ''N'' entries (1.125x or 2.25x as much memory on 64-bit systems). Both tables double in size at certain thresholds, and the thresholds for CloseTable are lower than those for OpenTable. That is, as a CloseTable is populated, it doubles in size sooner than the corresponding OpenTable. The factors determining this behavior are (1) the fact that CloseTable entries are 50% larger, and it therefore takes fewer of them to fill up a power-of-two-sized allocation; and (2) the value of <code>OpenTable::max_fill_factor()</code>.

It is tempting to reduce this complicated picture to a single number, and write that CloseTables are, for example, 20% larger. Or 30%. But such a number would not be easily justified mathematically: the ratio does not converge as the number of entries increases.

[[Image:jorendorff-dht-figure-2.png]]

DenseTable and OpenTable must initialize the entire table each time they resize. CloseTable also allocates large chunks of memory, but like a <code>vector</code>, it does not need to write to that memory until there is data that needs to be stored there.

This means that for a huge Map with no delete operations, a Close table could use more virtual memory but less physical memory than its open addressing counterparts. This will not be the only use case that stresses memory usage, though. Applications may also create many small tables and may delete entries from large tables.

== Insertion speed ==

[[Image:jorendorff-dht-InsertSmallTest-speed.png]]

This measures the time required to fill a table to about 100 entries, repeatedly. (The “1e7” on the axes indicates that the numbers are in tens of millions: the Close table is doing about 60 million inserts per second on this machine.)

This graph and the following ones show speed, so '''higher is better'''.

Ideally all these graphs would show three straight horizontal lines, indicating that all three implementations scale beautifully to large work loads. And indeed this seems to be the case, mostly.

[[Image:jorendorff-dht-InsertLargeTest-speed.png]]

This test measures the time required to fill a single gigantic table.

The jagged shape of this graph is robust. It reflects the fact that the table doubles in size as it grows, and rehashing is a significant part of the expense of populating a huge table.

== Lookup speed ==

[[Image:jorendorff-dht-LookupHitTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where ''k'' is the key of an existing entry in the table.

[[Image:jorendorff-dht-LookupMissTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where the key ''k'' is not found in the table.

In an OpenTable, lookups that miss are slower than lookups that hit ''when there is at least one collision''. This is because we keep probing the hash table until we find an empty entry.

DenseTable is only slightly slower for misses, perhaps because more lookups have zero collisions. (?)

== Deletion speed ==

[[Image:jorendorff-dht-WorklistTest-speed.png]]

This test creates a table with 700 entries, then measures the speed of alternately adding an entry and deleting the oldest remaining entry from the table. Entries are therefore removed in FIFO order. Each “operation” here includes both an insert and a delete.

The CloseTable stores the entries in insertion order, so this test gets extremely good memory locality. The effect is even more pronounced in a 32-bit build.

[[Image:jorendorff-dht-DeleteTest-speed.png]]

This test measures the speed of deleting all entries from a very large table.

The numbers for dense_hash_map are jagged because <code>DenseMap</code> shrinks the table at certain threshold sizes as entries are deleted, and shrinking the table is expensive.

The apparent randomness of the OpenTable and CloseTable numbers is reproducible and unexplained.

[[Image:jorendorff-dht-LookupAfterDeleteTest-speed.png]]

This test measures the performance of lookups, mostly misses, in a table that was filled to size 50000, then reduced to size 195 by deleting most of the entries.

The results here are sensitive to the two sizes, which are totally arbitrary choices. A less arbitrary replacement for this test would be welcome.

User:Jorend/Deterministic hash tables

2012-02-27T19:50:41Z

Jorend: /* Theory */ oops!

= Abstract =

A deterministic hash table proposed by Tyler Close was implemented in C++ and its performance was compared to two hash table implementations using open addressing. Speed and memory usage were measured.

'''Speed.''' The Close table implementation was very fast, faster than the open addressing implementations. (It is unclear why; theory suggests it "should" be slower, and measurement confirms that the Close table is doing more memory accesses and more branches. More investigation is needed!)

'''Memory.''' The Close table implementation always allocates more memory than the leanest open addressing implementation. See the Results section for details.

= Background =

Most hash table APIs (including C++'s <code>unordered_map</code>, Java's <code>java.util.HashMap</code>, Python's <code>dict</code>, Ruby's <code>Hash</code>, and many others) allow users to iterate over all the entries in the hash table in an arbitrary order. This exposes the user to an aspect of the library's behavior (the iteration order) that is unspecified and indeed intentionally arbitrary.

<code>Map</code> and <code>Set</code> data structures are proposed for a future version of the ECMAScript programming language. The standard committee would like to specify deterministic behavior if possible. There are several reasons for this:

* There is evidence that some programmers find arbitrary iteration order surprising or confusing at first. [http://stackoverflow.com/questions/2453624/unsort-hashtable][http://stackoverflow.com/questions/1872329/storing-python-dictionary-entries-in-the-order-they-are-pushed][https://groups.google.com/group/comp.lang.python/browse_thread/thread/15f3b4a5cd6221b1/1b6621daf5d78d73][http://bytes.com/topic/c-sharp/answers/439203-hashtable-items-order][http://stackoverflow.com/questions/1419708/how-to-keep-the-order-of-elements-in-hashtable][http://stackoverflow.com/questions/7105540/hashtable-values-reordered]
* Property enumeration order is unspecified in ECMAScript, yet all the major implementations have been forced to converge on insertion order, for compatibility with the Web as it is. There is, therefore, some concern that if TC39 does not specify a deterministic iteration order, “the web will just go and specify it for us”.[https://mail.mozilla.org/pipermail/es-discuss/2012-February/020576.html]
* Hash table iteration order can expose some bits of object hash codes. This imposes some astonishing security concerns on the hashing function implementer. For example, an object's address must not be recoverable from the exposed bits of its hash code. (Revealing object addresses to untrusted ECMAScript code, while not exploitable by itself, would be a bad security bug on the Web.)

Can a data structure retain the performance of traditional, arbitrary-order hash tables while also storing the order in which entries were added, so that iteration order is deterministic?

Tyler Close has developed a deterministic hash table that is structured like this (pseudocode):

struct Entry {
Key key;
Value value;
Entry *chain;
}

class CloseTable {
Entry*[] hashTable; // array of pointers into the data table
Entry[] dataTable;
}

Lookups and inserts proceed much like a bucket-and-chain hash table, but instead of each entry being allocated separately from the heap, they are stored in the <code>dataTable</code> in insertion order.

Removing an entry simply replaces its <code>key</code> with some sentinel while leaving the <code>chain</code> intact.

== Theory ==

'''Memory.''' Every map data structure must store the keys and values. A map with ''N'' entries must use at least ''NE'' memory, where ''E'' is the size of a key-value pair (we assume the data can’t be compressed).

In the following discussion we neglect the effect of deletions, which can cause both kinds of table to have extra memory that isn't in use at a given moment.

An open addressing hash table has additional overhead depending on the fill factor. <code>OpenTable</code> in particular has a maximum fill factor ''F''=3/4. When it becomes more than 3/4 full, it doubles in size, becoming just over 3/8 full. The amount of overhead in an <code>OpenTable</code> is ''(1/f)NE'', where ''f'' is the actual current fill ratio of the table and ''F/2 < f ≤ F''.

A Close table has three sources of overhead: the entire <code>hashTable</code>, the <code>chain</code> pointers in the <code>dataTable</code>, and the unused portion of the <code>dataTable</code>. In <code>CloseTable</code>, the <code>chain</code> pointer causes each entry to require ''(3/2)E'' memory rather than ''E''. The <code>dataTable</code> doubles in size when it becomes completely full, so its size is ''(3/2)(1/u)NE'' where ''u'' is the proportion of the <code>dataTable</code> that is in use and ''1/2 hashTable</code> is always 1/16 the size of the <code>dataTable</code> (1/8 on 64-bit platforms), so the total size of both tables is ''(1+1/16)(3/2)(1/u)NE'' (substitute 1/8 on 64-bit platforms).

For back-of-envelope purposes, then, ''f'' may be expected to be about ''3F/4'' (halfway between F/2 and F) and ''u'' about 3/4 on average; plugging these numbers in, we expect an <code>OpenTable</code> to use about (1/(3F/4)) = 1.78×''NE'', and a <code>CloseTable</code> about 2.13×''NE'' (2.25×''NE'' on 64-bit), on average. This would mean that the <code>CloseTable</code> would be 20% larger on average (27% larger on 64-bit). However, see the Results section for a picture of how the two implementations compare in practice.

'''Speed.''' We consider the speed of lookups only. The <code>get</code>, <code>has</code>, <code>set</code>, and <code>delete</code> operations all start with a lookup. We will quantify the speed of lookups in terms of how many memory locations must be accessed. To simulate locality effects, we treat multiple reads from a single entry, or from the table object, as a single read.

In an open addressing hash table with fill factor ''f'', an unsuccessful lookup performs about ''1/(1-f)'' probes.[https://en.wikipedia.org/wiki/Hash_table#Performance_analysis] In an <code>OpenTable</code>, at worst ''f=F=3/4'' and so an unsuccessful lookup performs 4 probes on average. In the usual case, ''f=3F/4=9/16'', so about 2.3 probes on average. A successful lookup performs half as many probes on average. Before probing the table, the lookup must access the <code>OpenTable</code> struct itself, so the final numbers are as shown in the table: 5 reads, 3.3 reads, etc.

A Close table uses direct chaining. Each lookup must read first the <code>CloseTable</code> object itself, and next the <code>hashTable</code>. Then, for an unsuccessful lookup, the whole chain is walked; the expected length of the chain is simply the number of keys in the table divided by the number of hash buckets. For a <code>CloseTable</code>, this quotient is at most 8/3 and typically 2. ...

<table class="data">
<tr>
<th></th>
<th colspan=2>Expected cost of unsuccessful lookup (miss)</th>
<th colspan=2>Expected cost of successful lookup (hit)</th>
</tr>
<tr>
<th>Data structure</th>
<th>Maximum load</th>
<th>Typical load</th>
<th>Maximum load</th>
<th>Typical load</th>
</tr>
<tr>
<td><code>OpenTable</code>
<td>5
<td>3.3
<td>3
<td>2.2
</tr>
<tr>
<td><code>CloseTable</code>
<td>4.7
<td>4
<td>-
<td>-
</tr>
</table>

= Method =

The code I used to make these pictures is available at: https://github.com/jorendorff/dht

The graphs below show data collected on a MacBook Pro, using g++-apple-4.2 and a 64-bit build. The results from running the test on a 32-bit Windows build were basically qualitatively the same. CloseTable performance was even better on Windows, for most tests; however, on LookupHitTest, OpenTable achieved almost equal speed.

The project contains two complete hash map implementations: OpenTable and CloseTable. A third implementation, DenseTable, is a thin wrapper around the <code>dense_hash_map</code> type from [https://code.google.com/p/sparsehash/ Sparsehash]. The three classes have the same API and were all benchmarked using the same templates (in hashbench.cpp).

Hash table implementation design notes:

* The API was designed to match the [http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets proposal for ECMAScript Map objects] as of February 2012.

* The Key and Value types are <code>uint64_t</code> because ECMAScript values are 64 bits in the implementation I'm most familiar with.

* OpenTable and CloseTable are meant to be as fast and as memory-efficient as possible. Pretty much everything that can be omitted was omitted. For example, the hashing function is trivial: ''hash(key) = key'', and neither OpenTable nor CloseTable further munges the hashcode before using it as a table index. Rationale: Making each implementation as fast as possible should highlight any performance difference between OpenTable and CloseTable, which is the purpose of the exercise. Using a more sophisticated hashing function would slow down both implementations, reducing the observed difference between the two techniques.

* DenseTable is provided as a baseline. (It's nice to have some realistic numbers in the graphs too.)

* dense_hash_map and OpenTable both implement straightforward hash tables with open addressing. The main difference between the two is one of tuning. dense_hash_map has a maximum load factor of 0.5. OpenTable has a maximum load factor of 0.75, which causes it to use about half as much memory most of the time.

* The purpose of the typedefs KeyArg and ValueArg is to make it possible to switch the API from pass-by-value to pass-by-reference by editing just a couple of lines of code. (I tried this. Pass-by-reference is no faster on 64-bit machines.)

* CloseTable attempts to allocate chunks of memory with sizes that are near powers of 2. This is to avoid wasting space when used with size-class-based malloc implementations.

* A Close table can trade some speed for compactness, but it seems to be a bad bargain:
** The load factor is adjustable. (The hash table size must remain at a power of two, but the data vector can have non-power-of-2 sizes.) However, increasing the load factor directly affects LookupMiss speed.
** An implementation could grow the data array by less than doubling it each time. I tried this. Insert speed suffered; lookup speed was unaffected; but the modified CloseTable still used more memory than OpenTable.

* <code>dense_hash_map</code> never shrinks the table unless you explicitly ask it to. <code>DenseTable::remove()</code> periodically shrinks, because otherwise, the performance on LookupAfterDeleteTest is pathologically bad.

Benchmark design notes:

* The benchmark is pure C++, rather than a Map/Set implementation embedded in an existing ES implementation, in order to make the results as stable as possible, to avoid biasing the results to a particular ES implementation, to encourage contributors, and to focus on the performance differences in the hash table implementations by eliminating all other performance effects as much as possible.

* The program runs each benchmark many different times in order to produce enough numbers that noise is visually obvious in the resulting graph. (Most of the speed graphs are nice and smooth.)

= Results =

== Memory usage ==

[[Image:jorendorff-dht-figure-1.png]]

All three implementations double the size of the table whenever it gets too full. On a log-log plot, this shows as stair-steps of a constant height. The slope of each staircase is 1, indicating linear growth.

Both OpenTable and CloseTable are much more memory-efficient than DenseTable, because <code>dense_hash_map</code> is tuned for fast lookups at all costs.

For any ''N'' > 5, a CloseTable with ''N'' entries allocates '''either 1.0625x or 2.125x as much memory''' as an OpenTable with ''N'' entries (1.125x or 2.25x as much memory on 64-bit systems). Both tables double in size at certain thresholds, and the thresholds for CloseTable are lower than those for OpenTable. That is, as a CloseTable is populated, it doubles in size sooner than the corresponding OpenTable. The factors determining this behavior are (1) the fact that CloseTable entries are 50% larger, and it therefore takes fewer of them to fill up a power-of-two-sized allocation; and (2) the value of <code>OpenTable::max_fill_factor()</code>.

It is tempting to reduce this complicated picture to a single number, and write that CloseTables are, for example, 20% larger. Or 30%. But such a number would not be easily justified mathematically: the ratio does not converge as the number of entries increases.

[[Image:jorendorff-dht-figure-2.png]]

DenseTable and OpenTable must initialize the entire table each time they resize. CloseTable also allocates large chunks of memory, but like a <code>vector</code>, it does not need to write to that memory until there is data that needs to be stored there.

This means that for a huge Map with no delete operations, a Close table could use more virtual memory but less physical memory than its open addressing counterparts. This will not be the only use case that stresses memory usage, though. Applications may also create many small tables and may delete entries from large tables.

== Insertion speed ==

[[Image:jorendorff-dht-InsertSmallTest-speed.png]]

This measures the time required to fill a table to about 100 entries, repeatedly. (The “1e7” on the axes indicates that the numbers are in tens of millions: the Close table is doing about 60 million inserts per second on this machine.)

This graph and the following ones show speed, so '''higher is better'''.

Ideally all these graphs would show three straight horizontal lines, indicating that all three implementations scale beautifully to large work loads. And indeed this seems to be the case, mostly.

[[Image:jorendorff-dht-InsertLargeTest-speed.png]]

This test measures the time required to fill a single gigantic table.

The jagged shape of this graph is robust. It reflects the fact that the table doubles in size as it grows, and rehashing is a significant part of the expense of populating a huge table.

== Lookup speed ==

[[Image:jorendorff-dht-LookupHitTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where ''k'' is the key of an existing entry in the table.

[[Image:jorendorff-dht-LookupMissTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where the key ''k'' is not found in the table.

In an OpenTable, lookups that miss are slower than lookups that hit ''when there is at least one collision''. This is because we keep probing the hash table until we find an empty entry.

DenseTable is only slightly slower for misses, perhaps because more lookups have zero collisions. (?)

== Deletion speed ==

[[Image:jorendorff-dht-WorklistTest-speed.png]]

This test creates a table with 700 entries, then measures the speed of alternately adding an entry and deleting the oldest remaining entry from the table. Entries are therefore removed in FIFO order. Each “operation” here includes both an insert and a delete.

The CloseTable stores the entries in insertion order, so this test gets extremely good memory locality. The effect is even more pronounced in a 32-bit build.

[[Image:jorendorff-dht-DeleteTest-speed.png]]

This test measures the speed of deleting all entries from a very large table.

The numbers for dense_hash_map are jagged because <code>DenseMap</code> shrinks the table at certain threshold sizes as entries are deleted, and shrinking the table is expensive.

The apparent randomness of the OpenTable and CloseTable numbers is reproducible and unexplained.

[[Image:jorendorff-dht-LookupAfterDeleteTest-speed.png]]

This test measures the performance of lookups, mostly misses, in a table that was filled to size 50000, then reduced to size 195 by deleting most of the entries.

The results here are sensitive to the two sizes, which are totally arbitrary choices. A less arbitrary replacement for this test would be welcome.

User:Jorend/Deterministic hash tables

2012-02-27T19:49:41Z

Jorend: /* Theory */

= Abstract =

A deterministic hash table proposed by Tyler Close was implemented in C++ and its performance was compared to two hash table implementations using open addressing. Speed and memory usage were measured.

'''Speed.''' The Close table implementation was very fast, faster than the open addressing implementations. (It is unclear why; theory suggests it "should" be slower, and measurement confirms that the Close table is doing more memory accesses and more branches. More investigation is needed!)

'''Memory.''' The Close table implementation always allocates more memory than the leanest open addressing implementation. See the Results section for details.

= Background =

Most hash table APIs (including C++'s <code>unordered_map</code>, Java's <code>java.util.HashMap</code>, Python's <code>dict</code>, Ruby's <code>Hash</code>, and many others) allow users to iterate over all the entries in the hash table in an arbitrary order. This exposes the user to an aspect of the library's behavior (the iteration order) that is unspecified and indeed intentionally arbitrary.

<code>Map</code> and <code>Set</code> data structures are proposed for a future version of the ECMAScript programming language. The standard committee would like to specify deterministic behavior if possible. There are several reasons for this:

* There is evidence that some programmers find arbitrary iteration order surprising or confusing at first. [http://stackoverflow.com/questions/2453624/unsort-hashtable][http://stackoverflow.com/questions/1872329/storing-python-dictionary-entries-in-the-order-they-are-pushed][https://groups.google.com/group/comp.lang.python/browse_thread/thread/15f3b4a5cd6221b1/1b6621daf5d78d73][http://bytes.com/topic/c-sharp/answers/439203-hashtable-items-order][http://stackoverflow.com/questions/1419708/how-to-keep-the-order-of-elements-in-hashtable][http://stackoverflow.com/questions/7105540/hashtable-values-reordered]
* Property enumeration order is unspecified in ECMAScript, yet all the major implementations have been forced to converge on insertion order, for compatibility with the Web as it is. There is, therefore, some concern that if TC39 does not specify a deterministic iteration order, “the web will just go and specify it for us”.[https://mail.mozilla.org/pipermail/es-discuss/2012-February/020576.html]
* Hash table iteration order can expose some bits of object hash codes. This imposes some astonishing security concerns on the hashing function implementer. For example, an object's address must not be recoverable from the exposed bits of its hash code. (Revealing object addresses to untrusted ECMAScript code, while not exploitable by itself, would be a bad security bug on the Web.)

Can a data structure retain the performance of traditional, arbitrary-order hash tables while also storing the order in which entries were added, so that iteration order is deterministic?

Tyler Close has developed a deterministic hash table that is structured like this (pseudocode):

struct Entry {
Key key;
Value value;
Entry *chain;
}

class CloseTable {
Entry*[] hashTable; // array of pointers into the data table
Entry[] dataTable;
}

Lookups and inserts proceed much like a bucket-and-chain hash table, but instead of each entry being allocated separately from the heap, they are stored in the <code>dataTable</code> in insertion order.

Removing an entry simply replaces its <code>key</code> with some sentinel while leaving the <code>chain</code> intact.

== Theory ==

'''Memory.''' Every map data structure must store the keys and values. A map with ''N'' entries must use at least ''NE'' memory, where ''E'' is the size of a key-value pair (we assume the data can’t be compressed).

In the following discussion we neglect the effect of deletions, which can cause both kinds of table to have extra memory that isn't in use at a given moment.

An open addressing hash table has additional overhead depending on the fill factor. <code>OpenTable</code> in particular has a maximum fill factor ''F''=3/4. When it becomes more than 3/4 full, it doubles in size, becoming just over 3/8 full. The amount of overhead in an <code>OpenTable</code> is ''(1/f)NE'', where ''f'' is the actual current fill ratio of the table and ''F/2 < f ≤ F''.

A Close table has three sources of overhead: the entire <code>hashTable</code>, the <code>chain</code> pointers in the <code>dataTable</code>, and the unused portion of the <code>dataTable</code>. In <code>CloseTable</code>, the <code>chain</code> pointer causes each entry to require ''(3/2)E'' memory rather than ''E''. The <code>dataTable</code> doubles in size when it becomes completely full, so its size is ''(3/2)(1/u)NE'' where ''u'' is the proportion of the <code>dataTable</code> that is in use and ''1/2 hashTable</code> is always 1/16 the size of the <code>dataTable</code> (1/8 on 64-bit platforms), so the total size of both tables is ''(1+1/16)(3/2)(1/u)NE'' (substitute 1/8 on 64-bit platforms).

For back-of-envelope purposes, then, ''f'' may be expected to be about ''3F/4'' (halfway between F/2 and F) and ''u'' about 3/4 on average; plugging these numbers in, we expect an <code>OpenTable</code> to use about (1/(3F/4)) = 1.78×''NE'', and a <code>CloseTable</code> about 2.13×''NE'' (2.25×''NE'' on 64-bit), on average. This would mean that the <code>CloseTable</code> would be 20% larger on average (27% larger on 64-bit). However, see the Results section for a picture of how the two implementations compare in practice.

'''Speed.''' We consider the speed of lookups only. The <code>get</code>, <code>has</code>, <code>set</code>, and <code>delete</code> operations all start with a lookup. We will quantify the speed of lookups in terms of how many memory locations must be accessed. To simulate locality effects, we treat multiple reads from a single entry, or from the table object, as a single read.

In an open addressing hash table with fill factor ''f'', an unsuccessful lookup performs about ''1/(1-f)'' probes.[https://en.wikipedia.org/wiki/Hash_table#Performance_analysis] In an <code>OpenTable</code>, at worst ''f=F=3/4'' and so an unsuccessful lookup performs 4 probes on average. In the usual case, ''f=3F/4=9/16'', so about 2.3 probes on average. A successful lookup performs half as many probes on average. Before probing the table, the lookup must access the <code>OpenTable</code> struct itself, so the final numbers are as shown in the table: 5 reads, 3.3 reads, etc.

A Close table uses direct chaining. Each lookup must read first the <code>CloseTable</code> object itself, and next the <code>hashTable</code>. Then, for an unsuccessful lookup, the whole chain is walked; the expected length of the chain is simply the number of keys in the table divided by the number of hash buckets. For a <code>CloseTable</code>, this quotient is at most 8/3 and typically 2. ...

<table class="data">
<tr>
<th></th>
<th colspan=2>Expected cost of unsuccessful lookup (miss)</th>
<th colspan=2>Expected cost of successful lookup (hit)</th>
</tr>
<tr>
<th>Data structure</th>
<th>Maximum load</th>
<th>Typical load</th>
<th>Maximum load</th>
<th>Typical load</th>
</tr>
<tr>
<td><code>OpenTable</code>
<td>5
<td>3.3
<td>3
<td>2.2
</tr>
<tr>
<td><code>CloseTable</code>
<td>4.7
<td>3
<td>-
<td>-
</tr>
</table>

= Method =

The code I used to make these pictures is available at: https://github.com/jorendorff/dht

The graphs below show data collected on a MacBook Pro, using g++-apple-4.2 and a 64-bit build. The results from running the test on a 32-bit Windows build were basically qualitatively the same. CloseTable performance was even better on Windows, for most tests; however, on LookupHitTest, OpenTable achieved almost equal speed.

The project contains two complete hash map implementations: OpenTable and CloseTable. A third implementation, DenseTable, is a thin wrapper around the <code>dense_hash_map</code> type from [https://code.google.com/p/sparsehash/ Sparsehash]. The three classes have the same API and were all benchmarked using the same templates (in hashbench.cpp).

Hash table implementation design notes:

* The API was designed to match the [http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets proposal for ECMAScript Map objects] as of February 2012.

* The Key and Value types are <code>uint64_t</code> because ECMAScript values are 64 bits in the implementation I'm most familiar with.

* OpenTable and CloseTable are meant to be as fast and as memory-efficient as possible. Pretty much everything that can be omitted was omitted. For example, the hashing function is trivial: ''hash(key) = key'', and neither OpenTable nor CloseTable further munges the hashcode before using it as a table index. Rationale: Making each implementation as fast as possible should highlight any performance difference between OpenTable and CloseTable, which is the purpose of the exercise. Using a more sophisticated hashing function would slow down both implementations, reducing the observed difference between the two techniques.

* DenseTable is provided as a baseline. (It's nice to have some realistic numbers in the graphs too.)

* dense_hash_map and OpenTable both implement straightforward hash tables with open addressing. The main difference between the two is one of tuning. dense_hash_map has a maximum load factor of 0.5. OpenTable has a maximum load factor of 0.75, which causes it to use about half as much memory most of the time.

* The purpose of the typedefs KeyArg and ValueArg is to make it possible to switch the API from pass-by-value to pass-by-reference by editing just a couple of lines of code. (I tried this. Pass-by-reference is no faster on 64-bit machines.)

* CloseTable attempts to allocate chunks of memory with sizes that are near powers of 2. This is to avoid wasting space when used with size-class-based malloc implementations.

* A Close table can trade some speed for compactness, but it seems to be a bad bargain:
** The load factor is adjustable. (The hash table size must remain at a power of two, but the data vector can have non-power-of-2 sizes.) However, increasing the load factor directly affects LookupMiss speed.
** An implementation could grow the data array by less than doubling it each time. I tried this. Insert speed suffered; lookup speed was unaffected; but the modified CloseTable still used more memory than OpenTable.

* <code>dense_hash_map</code> never shrinks the table unless you explicitly ask it to. <code>DenseTable::remove()</code> periodically shrinks, because otherwise, the performance on LookupAfterDeleteTest is pathologically bad.

Benchmark design notes:

* The benchmark is pure C++, rather than a Map/Set implementation embedded in an existing ES implementation, in order to make the results as stable as possible, to avoid biasing the results to a particular ES implementation, to encourage contributors, and to focus on the performance differences in the hash table implementations by eliminating all other performance effects as much as possible.

* The program runs each benchmark many different times in order to produce enough numbers that noise is visually obvious in the resulting graph. (Most of the speed graphs are nice and smooth.)

= Results =

== Memory usage ==

[[Image:jorendorff-dht-figure-1.png]]

All three implementations double the size of the table whenever it gets too full. On a log-log plot, this shows as stair-steps of a constant height. The slope of each staircase is 1, indicating linear growth.

Both OpenTable and CloseTable are much more memory-efficient than DenseTable, because <code>dense_hash_map</code> is tuned for fast lookups at all costs.

For any ''N'' > 5, a CloseTable with ''N'' entries allocates '''either 1.0625x or 2.125x as much memory''' as an OpenTable with ''N'' entries (1.125x or 2.25x as much memory on 64-bit systems). Both tables double in size at certain thresholds, and the thresholds for CloseTable are lower than those for OpenTable. That is, as a CloseTable is populated, it doubles in size sooner than the corresponding OpenTable. The factors determining this behavior are (1) the fact that CloseTable entries are 50% larger, and it therefore takes fewer of them to fill up a power-of-two-sized allocation; and (2) the value of <code>OpenTable::max_fill_factor()</code>.

It is tempting to reduce this complicated picture to a single number, and write that CloseTables are, for example, 20% larger. Or 30%. But such a number would not be easily justified mathematically: the ratio does not converge as the number of entries increases.

[[Image:jorendorff-dht-figure-2.png]]

DenseTable and OpenTable must initialize the entire table each time they resize. CloseTable also allocates large chunks of memory, but like a <code>vector</code>, it does not need to write to that memory until there is data that needs to be stored there.

This means that for a huge Map with no delete operations, a Close table could use more virtual memory but less physical memory than its open addressing counterparts. This will not be the only use case that stresses memory usage, though. Applications may also create many small tables and may delete entries from large tables.

== Insertion speed ==

[[Image:jorendorff-dht-InsertSmallTest-speed.png]]

This measures the time required to fill a table to about 100 entries, repeatedly. (The “1e7” on the axes indicates that the numbers are in tens of millions: the Close table is doing about 60 million inserts per second on this machine.)

This graph and the following ones show speed, so '''higher is better'''.

Ideally all these graphs would show three straight horizontal lines, indicating that all three implementations scale beautifully to large work loads. And indeed this seems to be the case, mostly.

[[Image:jorendorff-dht-InsertLargeTest-speed.png]]

This test measures the time required to fill a single gigantic table.

The jagged shape of this graph is robust. It reflects the fact that the table doubles in size as it grows, and rehashing is a significant part of the expense of populating a huge table.

== Lookup speed ==

[[Image:jorendorff-dht-LookupHitTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where ''k'' is the key of an existing entry in the table.

[[Image:jorendorff-dht-LookupMissTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where the key ''k'' is not found in the table.

In an OpenTable, lookups that miss are slower than lookups that hit ''when there is at least one collision''. This is because we keep probing the hash table until we find an empty entry.

DenseTable is only slightly slower for misses, perhaps because more lookups have zero collisions. (?)

== Deletion speed ==

[[Image:jorendorff-dht-WorklistTest-speed.png]]

This test creates a table with 700 entries, then measures the speed of alternately adding an entry and deleting the oldest remaining entry from the table. Entries are therefore removed in FIFO order. Each “operation” here includes both an insert and a delete.

The CloseTable stores the entries in insertion order, so this test gets extremely good memory locality. The effect is even more pronounced in a 32-bit build.

[[Image:jorendorff-dht-DeleteTest-speed.png]]

This test measures the speed of deleting all entries from a very large table.

The numbers for dense_hash_map are jagged because <code>DenseMap</code> shrinks the table at certain threshold sizes as entries are deleted, and shrinking the table is expensive.

The apparent randomness of the OpenTable and CloseTable numbers is reproducible and unexplained.

[[Image:jorendorff-dht-LookupAfterDeleteTest-speed.png]]

This test measures the performance of lookups, mostly misses, in a table that was filled to size 50000, then reduced to size 195 by deleting most of the entries.

The results here are sensitive to the two sizes, which are totally arbitrary choices. A less arbitrary replacement for this test would be welcome.

User:Jorend/Deterministic hash tables

2012-02-27T19:46:50Z

Jorend: /* Theory */ fmt

= Abstract =

A deterministic hash table proposed by Tyler Close was implemented in C++ and its performance was compared to two hash table implementations using open addressing. Speed and memory usage were measured.

'''Speed.''' The Close table implementation was very fast, faster than the open addressing implementations. (It is unclear why; theory suggests it "should" be slower, and measurement confirms that the Close table is doing more memory accesses and more branches. More investigation is needed!)

'''Memory.''' The Close table implementation always allocates more memory than the leanest open addressing implementation. See the Results section for details.

= Background =

Most hash table APIs (including C++'s <code>unordered_map</code>, Java's <code>java.util.HashMap</code>, Python's <code>dict</code>, Ruby's <code>Hash</code>, and many others) allow users to iterate over all the entries in the hash table in an arbitrary order. This exposes the user to an aspect of the library's behavior (the iteration order) that is unspecified and indeed intentionally arbitrary.

<code>Map</code> and <code>Set</code> data structures are proposed for a future version of the ECMAScript programming language. The standard committee would like to specify deterministic behavior if possible. There are several reasons for this:

* There is evidence that some programmers find arbitrary iteration order surprising or confusing at first. [http://stackoverflow.com/questions/2453624/unsort-hashtable][http://stackoverflow.com/questions/1872329/storing-python-dictionary-entries-in-the-order-they-are-pushed][https://groups.google.com/group/comp.lang.python/browse_thread/thread/15f3b4a5cd6221b1/1b6621daf5d78d73][http://bytes.com/topic/c-sharp/answers/439203-hashtable-items-order][http://stackoverflow.com/questions/1419708/how-to-keep-the-order-of-elements-in-hashtable][http://stackoverflow.com/questions/7105540/hashtable-values-reordered]
* Property enumeration order is unspecified in ECMAScript, yet all the major implementations have been forced to converge on insertion order, for compatibility with the Web as it is. There is, therefore, some concern that if TC39 does not specify a deterministic iteration order, “the web will just go and specify it for us”.[https://mail.mozilla.org/pipermail/es-discuss/2012-February/020576.html]
* Hash table iteration order can expose some bits of object hash codes. This imposes some astonishing security concerns on the hashing function implementer. For example, an object's address must not be recoverable from the exposed bits of its hash code. (Revealing object addresses to untrusted ECMAScript code, while not exploitable by itself, would be a bad security bug on the Web.)

Can a data structure retain the performance of traditional, arbitrary-order hash tables while also storing the order in which entries were added, so that iteration order is deterministic?

Tyler Close has developed a deterministic hash table that is structured like this (pseudocode):

struct Entry {
Key key;
Value value;
Entry *chain;
}

class CloseTable {
Entry*[] hashTable; // array of pointers into the data table
Entry[] dataTable;
}

Lookups and inserts proceed much like a bucket-and-chain hash table, but instead of each entry being allocated separately from the heap, they are stored in the <code>dataTable</code> in insertion order.

Removing an entry simply replaces its <code>key</code> with some sentinel while leaving the <code>chain</code> intact.

== Theory ==

'''Memory.''' Every map data structure must store the keys and values. A map with ''N'' entries must use at least ''NE'' memory, where ''E'' is the size of a key-value pair (we assume the data can’t be compressed).

In the following discussion we neglect the effect of deletions, which can cause both kinds of table to have extra memory that isn't in use at a given moment.

An open addressing hash table has additional overhead depending on the fill factor. <code>OpenTable</code> in particular has a maximum fill factor ''F''=3/4. When it becomes more than 3/4 full, it doubles in size, becoming just over 3/8 full. The amount of overhead in an <code>OpenTable</code> is ''(1/f)NE'', where ''f'' is the actual current fill ratio of the table and ''F/2 < f ≤ F''.

A Close table has three sources of overhead: the entire <code>hashTable</code>, the <code>chain</code> pointers in the <code>dataTable</code>, and the unused portion of the <code>dataTable</code>. In <code>CloseTable</code>, the <code>chain</code> pointer causes each entry to require ''(3/2)E'' memory rather than ''E''. The <code>dataTable</code> doubles in size when it becomes completely full, so its size is ''(3/2)(1/u)NE'' where ''u'' is the proportion of the <code>dataTable</code> that is in use and ''1/2 hashTable</code> is always 1/16 the size of the <code>dataTable</code> (1/8 on 64-bit platforms), so the total size of both tables is ''(1+1/16)(3/2)(1/u)NE'' (substitute 1/8 on 64-bit platforms).

For back-of-envelope purposes, then, ''f'' may be expected to be about ''3F/4'' (halfway between F/2 and F) and ''u'' about 3/4 on average; plugging these numbers in, we expect an <code>OpenTable</code> to have about (1/(3F/4))×100% - 100% = 78% memory overhead, and a <code>CloseTable</code> about 113% (125% on 64-bit), on average. This would mean that the <code>CloseTable</code> would be 20% larger on average (27% larger on 64-bit). However, see the Results section for a picture of how the two implementations compare in practice.

'''Speed.''' We consider the speed of lookups only. The <code>get</code>, <code>has</code>, <code>set</code>, and <code>delete</code> operations all start with a lookup. We will quantify the speed of lookups in terms of how many memory locations must be accessed. To simulate locality effects, we treat multiple reads from a single entry, or from the table object, as a single read.

In an open addressing hash table with fill factor ''f'', an unsuccessful lookup performs about ''1/(1-f)'' probes.[https://en.wikipedia.org/wiki/Hash_table#Performance_analysis] In an <code>OpenTable</code>, at worst ''f=F=3/4'' and so an unsuccessful lookup performs 4 probes on average. In the usual case, ''f=3F/4=9/16'', so about 2.3 probes on average. A successful lookup performs half as many probes on average. Before probing the table, the lookup must access the <code>OpenTable</code> struct itself, so the final numbers are as shown in the table: 5 reads, 3.3 reads, etc.

A Close table uses direct chaining. Each lookup must read first the <code>CloseTable</code> object itself, and next the <code>hashTable</code>. Then, for an unsuccessful lookup, the whole chain is walked; the expected length of the chain is simply the number of keys in the table divided by the number of hash buckets. For a <code>CloseTable</code>, this quotient is at most 8/3 and typically 2. ...

<table class="data">
<tr>
<th></th>
<th colspan=2>Expected cost of unsuccessful lookup (miss)</th>
<th colspan=2>Expected cost of successful lookup (hit)</th>
</tr>
<tr>
<th>Data structure</th>
<th>Maximum load</th>
<th>Typical load</th>
<th>Maximum load</th>
<th>Typical load</th>
</tr>
<tr>
<td><code>OpenTable</code>
<td>5
<td>3.3
<td>3
<td>2.2
</tr>
<tr>
<td><code>CloseTable</code>
<td>4.7
<td>3
<td>-
<td>-
</tr>
</table>

= Method =

The code I used to make these pictures is available at: https://github.com/jorendorff/dht

The graphs below show data collected on a MacBook Pro, using g++-apple-4.2 and a 64-bit build. The results from running the test on a 32-bit Windows build were basically qualitatively the same. CloseTable performance was even better on Windows, for most tests; however, on LookupHitTest, OpenTable achieved almost equal speed.

The project contains two complete hash map implementations: OpenTable and CloseTable. A third implementation, DenseTable, is a thin wrapper around the <code>dense_hash_map</code> type from [https://code.google.com/p/sparsehash/ Sparsehash]. The three classes have the same API and were all benchmarked using the same templates (in hashbench.cpp).

Hash table implementation design notes:

* The API was designed to match the [http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets proposal for ECMAScript Map objects] as of February 2012.

* The Key and Value types are <code>uint64_t</code> because ECMAScript values are 64 bits in the implementation I'm most familiar with.

* OpenTable and CloseTable are meant to be as fast and as memory-efficient as possible. Pretty much everything that can be omitted was omitted. For example, the hashing function is trivial: ''hash(key) = key'', and neither OpenTable nor CloseTable further munges the hashcode before using it as a table index. Rationale: Making each implementation as fast as possible should highlight any performance difference between OpenTable and CloseTable, which is the purpose of the exercise. Using a more sophisticated hashing function would slow down both implementations, reducing the observed difference between the two techniques.

* DenseTable is provided as a baseline. (It's nice to have some realistic numbers in the graphs too.)

* dense_hash_map and OpenTable both implement straightforward hash tables with open addressing. The main difference between the two is one of tuning. dense_hash_map has a maximum load factor of 0.5. OpenTable has a maximum load factor of 0.75, which causes it to use about half as much memory most of the time.

* The purpose of the typedefs KeyArg and ValueArg is to make it possible to switch the API from pass-by-value to pass-by-reference by editing just a couple of lines of code. (I tried this. Pass-by-reference is no faster on 64-bit machines.)

* CloseTable attempts to allocate chunks of memory with sizes that are near powers of 2. This is to avoid wasting space when used with size-class-based malloc implementations.

* A Close table can trade some speed for compactness, but it seems to be a bad bargain:
** The load factor is adjustable. (The hash table size must remain at a power of two, but the data vector can have non-power-of-2 sizes.) However, increasing the load factor directly affects LookupMiss speed.
** An implementation could grow the data array by less than doubling it each time. I tried this. Insert speed suffered; lookup speed was unaffected; but the modified CloseTable still used more memory than OpenTable.

* <code>dense_hash_map</code> never shrinks the table unless you explicitly ask it to. <code>DenseTable::remove()</code> periodically shrinks, because otherwise, the performance on LookupAfterDeleteTest is pathologically bad.

Benchmark design notes:

* The benchmark is pure C++, rather than a Map/Set implementation embedded in an existing ES implementation, in order to make the results as stable as possible, to avoid biasing the results to a particular ES implementation, to encourage contributors, and to focus on the performance differences in the hash table implementations by eliminating all other performance effects as much as possible.

* The program runs each benchmark many different times in order to produce enough numbers that noise is visually obvious in the resulting graph. (Most of the speed graphs are nice and smooth.)

= Results =

== Memory usage ==

[[Image:jorendorff-dht-figure-1.png]]

All three implementations double the size of the table whenever it gets too full. On a log-log plot, this shows as stair-steps of a constant height. The slope of each staircase is 1, indicating linear growth.

Both OpenTable and CloseTable are much more memory-efficient than DenseTable, because <code>dense_hash_map</code> is tuned for fast lookups at all costs.

For any ''N'' > 5, a CloseTable with ''N'' entries allocates '''either 1.0625x or 2.125x as much memory''' as an OpenTable with ''N'' entries (1.125x or 2.25x as much memory on 64-bit systems). Both tables double in size at certain thresholds, and the thresholds for CloseTable are lower than those for OpenTable. That is, as a CloseTable is populated, it doubles in size sooner than the corresponding OpenTable. The factors determining this behavior are (1) the fact that CloseTable entries are 50% larger, and it therefore takes fewer of them to fill up a power-of-two-sized allocation; and (2) the value of <code>OpenTable::max_fill_factor()</code>.

It is tempting to reduce this complicated picture to a single number, and write that CloseTables are, for example, 20% larger. Or 30%. But such a number would not be easily justified mathematically: the ratio does not converge as the number of entries increases.

[[Image:jorendorff-dht-figure-2.png]]

DenseTable and OpenTable must initialize the entire table each time they resize. CloseTable also allocates large chunks of memory, but like a <code>vector</code>, it does not need to write to that memory until there is data that needs to be stored there.

This means that for a huge Map with no delete operations, a Close table could use more virtual memory but less physical memory than its open addressing counterparts. This will not be the only use case that stresses memory usage, though. Applications may also create many small tables and may delete entries from large tables.

== Insertion speed ==

[[Image:jorendorff-dht-InsertSmallTest-speed.png]]

This measures the time required to fill a table to about 100 entries, repeatedly. (The “1e7” on the axes indicates that the numbers are in tens of millions: the Close table is doing about 60 million inserts per second on this machine.)

This graph and the following ones show speed, so '''higher is better'''.

Ideally all these graphs would show three straight horizontal lines, indicating that all three implementations scale beautifully to large work loads. And indeed this seems to be the case, mostly.

[[Image:jorendorff-dht-InsertLargeTest-speed.png]]

This test measures the time required to fill a single gigantic table.

The jagged shape of this graph is robust. It reflects the fact that the table doubles in size as it grows, and rehashing is a significant part of the expense of populating a huge table.

== Lookup speed ==

[[Image:jorendorff-dht-LookupHitTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where ''k'' is the key of an existing entry in the table.

[[Image:jorendorff-dht-LookupMissTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where the key ''k'' is not found in the table.

In an OpenTable, lookups that miss are slower than lookups that hit ''when there is at least one collision''. This is because we keep probing the hash table until we find an empty entry.

DenseTable is only slightly slower for misses, perhaps because more lookups have zero collisions. (?)

== Deletion speed ==

[[Image:jorendorff-dht-WorklistTest-speed.png]]

This test creates a table with 700 entries, then measures the speed of alternately adding an entry and deleting the oldest remaining entry from the table. Entries are therefore removed in FIFO order. Each “operation” here includes both an insert and a delete.

The CloseTable stores the entries in insertion order, so this test gets extremely good memory locality. The effect is even more pronounced in a 32-bit build.

[[Image:jorendorff-dht-DeleteTest-speed.png]]

This test measures the speed of deleting all entries from a very large table.

The numbers for dense_hash_map are jagged because <code>DenseMap</code> shrinks the table at certain threshold sizes as entries are deleted, and shrinking the table is expensive.

The apparent randomness of the OpenTable and CloseTable numbers is reproducible and unexplained.

[[Image:jorendorff-dht-LookupAfterDeleteTest-speed.png]]

This test measures the performance of lookups, mostly misses, in a table that was filled to size 50000, then reduced to size 195 by deleting most of the entries.

The results here are sensitive to the two sizes, which are totally arbitrary choices. A less arbitrary replacement for this test would be welcome.

User:Jorend/Deterministic hash tables

2012-02-27T19:39:58Z

Jorend: /* Theory */

= Abstract =

A deterministic hash table proposed by Tyler Close was implemented in C++ and its performance was compared to two hash table implementations using open addressing. Speed and memory usage were measured.

'''Speed.''' The Close table implementation was very fast, faster than the open addressing implementations. (It is unclear why; theory suggests it "should" be slower, and measurement confirms that the Close table is doing more memory accesses and more branches. More investigation is needed!)

'''Memory.''' The Close table implementation always allocates more memory than the leanest open addressing implementation. See the Results section for details.

= Background =

Most hash table APIs (including C++'s <code>unordered_map</code>, Java's <code>java.util.HashMap</code>, Python's <code>dict</code>, Ruby's <code>Hash</code>, and many others) allow users to iterate over all the entries in the hash table in an arbitrary order. This exposes the user to an aspect of the library's behavior (the iteration order) that is unspecified and indeed intentionally arbitrary.

<code>Map</code> and <code>Set</code> data structures are proposed for a future version of the ECMAScript programming language. The standard committee would like to specify deterministic behavior if possible. There are several reasons for this:

* There is evidence that some programmers find arbitrary iteration order surprising or confusing at first. [http://stackoverflow.com/questions/2453624/unsort-hashtable][http://stackoverflow.com/questions/1872329/storing-python-dictionary-entries-in-the-order-they-are-pushed][https://groups.google.com/group/comp.lang.python/browse_thread/thread/15f3b4a5cd6221b1/1b6621daf5d78d73][http://bytes.com/topic/c-sharp/answers/439203-hashtable-items-order][http://stackoverflow.com/questions/1419708/how-to-keep-the-order-of-elements-in-hashtable][http://stackoverflow.com/questions/7105540/hashtable-values-reordered]
* Property enumeration order is unspecified in ECMAScript, yet all the major implementations have been forced to converge on insertion order, for compatibility with the Web as it is. There is, therefore, some concern that if TC39 does not specify a deterministic iteration order, “the web will just go and specify it for us”.[https://mail.mozilla.org/pipermail/es-discuss/2012-February/020576.html]
* Hash table iteration order can expose some bits of object hash codes. This imposes some astonishing security concerns on the hashing function implementer. For example, an object's address must not be recoverable from the exposed bits of its hash code. (Revealing object addresses to untrusted ECMAScript code, while not exploitable by itself, would be a bad security bug on the Web.)

Can a data structure retain the performance of traditional, arbitrary-order hash tables while also storing the order in which entries were added, so that iteration order is deterministic?

Tyler Close has developed a deterministic hash table that is structured like this (pseudocode):

struct Entry {
Key key;
Value value;
Entry *chain;
}

class CloseTable {
Entry*[] hashTable; // array of pointers into the data table
Entry[] dataTable;
}

Lookups and inserts proceed much like a bucket-and-chain hash table, but instead of each entry being allocated separately from the heap, they are stored in the <code>dataTable</code> in insertion order.

Removing an entry simply replaces its <code>key</code> with some sentinel while leaving the <code>chain</code> intact.

== Theory ==

'''Memory.''' Every map data structure must store the keys and values. A map with ''N'' entries must use at least ''NE'' memory, where ''E'' is the size of a key-value pair (we assume the data can’t be compressed).

In the following discussion we neglect the effect of deletions, which can cause both kinds of table to have extra memory that isn't in use at a given moment.

An open addressing hash table has additional overhead depending on the fill factor. <code>OpenTable</code> in particular has a maximum fill factor ''F''=3/4. When it becomes more than 3/4 full, it doubles in size, becoming just over 3/8 full. The amount of overhead in an <code>OpenTable</code> is ''(1/f)NE'', where ''f'' is the actual current fill ratio of the table and ''F/2 < f ≤ F''.

A Close table has three sources of overhead: the entire <code>hashTable</code>, the <code>chain</code> pointers in the <code>dataTable</code>, and the unused portion of the <code>dataTable</code>. In <code>CloseTable</code>, the <code>chain</code> pointer causes each entry to require ''(3/2)E'' memory rather than ''E''. The <code>dataTable</code> doubles in size when it becomes completely full, so its size is ''(3/2)(1/u)NE'' where ''u'' is the proportion of the <code>dataTable</code> that is in use and ''1/2 hashTable</code> is always 1/16 the size of the <code>dataTable</code> (1/8 on 64-bit platforms), so the total size of both tables is ''(1+1/16)(3/2)(1/u)NE'' (substitute 1/8 on 64-bit platforms).

For back-of-envelope purposes, then, ''f'' may be expected to be about ''3F/4'' (halfway between F/2 and F) and ''u'' about 3/4 on average; plugging these numbers in, we expect an <code>OpenTable</code> to have about (1/(3F/4))&times100%-100% = 78% memory overhead, and a <code>CloseTable</code> about 113% (125% on 64-bit), on average. This would mean that the <code>CloseTable</code> would be 20% larger on average (27% larger on 64-bit). However, see the Results section for a picture of how the two implementations compare in practice.

'''Speed.''' We consider the speed of lookups only. The <code>get</code>, <code>has</code>, <code>set</code>, and <code>delete</code> operations all start with a lookup. We will quantify the speed of lookups in terms of how many memory locations must be accessed. To simulate locality effects, we treat multiple reads from a single entry, or from the table object, as a single read.

In an open addressing hash table with fill factor ''f'', an unsuccessful lookup performs about ''1/(1-f)'' probes.[https://en.wikipedia.org/wiki/Hash_table#Performance_analysis] In an <code>OpenTable</code>, at worst ''f=F=3/4'' and so an unsuccessful lookup performs 4 probes on average. In the usual case, ''f=3F/4=9/16'', so about 2.3 probes on average. A successful lookup performs half as many probes on average. Before probing the table, the lookup must access the <code>OpenTable</code> struct itself, so the final numbers are as shown in the table: 5 reads, 3.3 reads, etc.

A Close table uses direct chaining. Each lookup must read first the <code>CloseTable</code> object itself, and next the <code>hashTable</code>. Then, for an unsuccessful lookup, the whole chain is walked; the expected length of the chain is simply the number of keys in the table divided by the number of hash buckets. For a <code>CloseTable</code>, this quotient is at most 8/3 and typically 2. ...

<table class="data">
<tr>
<th rowspan=2>Data structure</th>
<th colspan=2>Expected cost of unsuccessful lookup (miss)</th>
<th colspan=2>Expected cost of successful lookup (hit)</th>
</tr>
<tr>
<th>Maximum load</th>
<th>Typical load</th>
<th>Maximum load</th>
<th>Typical load</th>
</tr>
<tr>
<td><code>OpenTable</code>
<td>5
<td>3.3
<td>3
<td>2.2
</tr>
<tr>
<td><code>CloseTable</code>
<td>4.7
<td>3
<td>-
<td>-
</tr>
</table>

= Method =

The code I used to make these pictures is available at: https://github.com/jorendorff/dht

The graphs below show data collected on a MacBook Pro, using g++-apple-4.2 and a 64-bit build. The results from running the test on a 32-bit Windows build were basically qualitatively the same. CloseTable performance was even better on Windows, for most tests; however, on LookupHitTest, OpenTable achieved almost equal speed.

The project contains two complete hash map implementations: OpenTable and CloseTable. A third implementation, DenseTable, is a thin wrapper around the <code>dense_hash_map</code> type from [https://code.google.com/p/sparsehash/ Sparsehash]. The three classes have the same API and were all benchmarked using the same templates (in hashbench.cpp).

Hash table implementation design notes:

* The API was designed to match the [http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets proposal for ECMAScript Map objects] as of February 2012.

* The Key and Value types are <code>uint64_t</code> because ECMAScript values are 64 bits in the implementation I'm most familiar with.

* OpenTable and CloseTable are meant to be as fast and as memory-efficient as possible. Pretty much everything that can be omitted was omitted. For example, the hashing function is trivial: ''hash(key) = key'', and neither OpenTable nor CloseTable further munges the hashcode before using it as a table index. Rationale: Making each implementation as fast as possible should highlight any performance difference between OpenTable and CloseTable, which is the purpose of the exercise. Using a more sophisticated hashing function would slow down both implementations, reducing the observed difference between the two techniques.

* DenseTable is provided as a baseline. (It's nice to have some realistic numbers in the graphs too.)

* dense_hash_map and OpenTable both implement straightforward hash tables with open addressing. The main difference between the two is one of tuning. dense_hash_map has a maximum load factor of 0.5. OpenTable has a maximum load factor of 0.75, which causes it to use about half as much memory most of the time.

* The purpose of the typedefs KeyArg and ValueArg is to make it possible to switch the API from pass-by-value to pass-by-reference by editing just a couple of lines of code. (I tried this. Pass-by-reference is no faster on 64-bit machines.)

* CloseTable attempts to allocate chunks of memory with sizes that are near powers of 2. This is to avoid wasting space when used with size-class-based malloc implementations.

* A Close table can trade some speed for compactness, but it seems to be a bad bargain:
** The load factor is adjustable. (The hash table size must remain at a power of two, but the data vector can have non-power-of-2 sizes.) However, increasing the load factor directly affects LookupMiss speed.
** An implementation could grow the data array by less than doubling it each time. I tried this. Insert speed suffered; lookup speed was unaffected; but the modified CloseTable still used more memory than OpenTable.

* <code>dense_hash_map</code> never shrinks the table unless you explicitly ask it to. <code>DenseTable::remove()</code> periodically shrinks, because otherwise, the performance on LookupAfterDeleteTest is pathologically bad.

Benchmark design notes:

* The benchmark is pure C++, rather than a Map/Set implementation embedded in an existing ES implementation, in order to make the results as stable as possible, to avoid biasing the results to a particular ES implementation, to encourage contributors, and to focus on the performance differences in the hash table implementations by eliminating all other performance effects as much as possible.

* The program runs each benchmark many different times in order to produce enough numbers that noise is visually obvious in the resulting graph. (Most of the speed graphs are nice and smooth.)

= Results =

== Memory usage ==

[[Image:jorendorff-dht-figure-1.png]]

All three implementations double the size of the table whenever it gets too full. On a log-log plot, this shows as stair-steps of a constant height. The slope of each staircase is 1, indicating linear growth.

Both OpenTable and CloseTable are much more memory-efficient than DenseTable, because <code>dense_hash_map</code> is tuned for fast lookups at all costs.

For any ''N'' > 5, a CloseTable with ''N'' entries allocates '''either 1.0625x or 2.125x as much memory''' as an OpenTable with ''N'' entries (1.125x or 2.25x as much memory on 64-bit systems). Both tables double in size at certain thresholds, and the thresholds for CloseTable are lower than those for OpenTable. That is, as a CloseTable is populated, it doubles in size sooner than the corresponding OpenTable. The factors determining this behavior are (1) the fact that CloseTable entries are 50% larger, and it therefore takes fewer of them to fill up a power-of-two-sized allocation; and (2) the value of <code>OpenTable::max_fill_factor()</code>.

It is tempting to reduce this complicated picture to a single number, and write that CloseTables are, for example, 20% larger. Or 30%. But such a number would not be easily justified mathematically: the ratio does not converge as the number of entries increases.

[[Image:jorendorff-dht-figure-2.png]]

DenseTable and OpenTable must initialize the entire table each time they resize. CloseTable also allocates large chunks of memory, but like a <code>vector</code>, it does not need to write to that memory until there is data that needs to be stored there.

This means that for a huge Map with no delete operations, a Close table could use more virtual memory but less physical memory than its open addressing counterparts. This will not be the only use case that stresses memory usage, though. Applications may also create many small tables and may delete entries from large tables.

== Insertion speed ==

[[Image:jorendorff-dht-InsertSmallTest-speed.png]]

This measures the time required to fill a table to about 100 entries, repeatedly. (The “1e7” on the axes indicates that the numbers are in tens of millions: the Close table is doing about 60 million inserts per second on this machine.)

This graph and the following ones show speed, so '''higher is better'''.

Ideally all these graphs would show three straight horizontal lines, indicating that all three implementations scale beautifully to large work loads. And indeed this seems to be the case, mostly.

[[Image:jorendorff-dht-InsertLargeTest-speed.png]]

This test measures the time required to fill a single gigantic table.

The jagged shape of this graph is robust. It reflects the fact that the table doubles in size as it grows, and rehashing is a significant part of the expense of populating a huge table.

== Lookup speed ==

[[Image:jorendorff-dht-LookupHitTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where ''k'' is the key of an existing entry in the table.

[[Image:jorendorff-dht-LookupMissTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where the key ''k'' is not found in the table.

In an OpenTable, lookups that miss are slower than lookups that hit ''when there is at least one collision''. This is because we keep probing the hash table until we find an empty entry.

DenseTable is only slightly slower for misses, perhaps because more lookups have zero collisions. (?)

== Deletion speed ==

[[Image:jorendorff-dht-WorklistTest-speed.png]]

This test creates a table with 700 entries, then measures the speed of alternately adding an entry and deleting the oldest remaining entry from the table. Entries are therefore removed in FIFO order. Each “operation” here includes both an insert and a delete.

The CloseTable stores the entries in insertion order, so this test gets extremely good memory locality. The effect is even more pronounced in a 32-bit build.

[[Image:jorendorff-dht-DeleteTest-speed.png]]

This test measures the speed of deleting all entries from a very large table.

The numbers for dense_hash_map are jagged because <code>DenseMap</code> shrinks the table at certain threshold sizes as entries are deleted, and shrinking the table is expensive.

The apparent randomness of the OpenTable and CloseTable numbers is reproducible and unexplained.

[[Image:jorendorff-dht-LookupAfterDeleteTest-speed.png]]

This test measures the performance of lookups, mostly misses, in a table that was filled to size 50000, then reduced to size 195 by deleting most of the entries.

The results here are sensitive to the two sizes, which are totally arbitrary choices. A less arbitrary replacement for this test would be welcome.

User:Jorend/Deterministic hash tables

2012-02-27T19:13:34Z

Jorend: /* Theory */ fmt

= Abstract =

A deterministic hash table proposed by Tyler Close was implemented in C++ and its performance was compared to two hash table implementations using open addressing. Speed and memory usage were measured.

'''Speed.''' The Close table implementation was very fast, faster than the open addressing implementations. (It is unclear why; theory suggests it "should" be slower, and measurement confirms that the Close table is doing more memory accesses and more branches. More investigation is needed!)

'''Memory.''' The Close table implementation always allocates more memory than the leanest open addressing implementation. See the Results section for details.

= Background =

Most hash table APIs (including C++'s <code>unordered_map</code>, Java's <code>java.util.HashMap</code>, Python's <code>dict</code>, Ruby's <code>Hash</code>, and many others) allow users to iterate over all the entries in the hash table in an arbitrary order. This exposes the user to an aspect of the library's behavior (the iteration order) that is unspecified and indeed intentionally arbitrary.

<code>Map</code> and <code>Set</code> data structures are proposed for a future version of the ECMAScript programming language. The standard committee would like to specify deterministic behavior if possible. There are several reasons for this:

* There is evidence that some programmers find arbitrary iteration order surprising or confusing at first. [http://stackoverflow.com/questions/2453624/unsort-hashtable][http://stackoverflow.com/questions/1872329/storing-python-dictionary-entries-in-the-order-they-are-pushed][https://groups.google.com/group/comp.lang.python/browse_thread/thread/15f3b4a5cd6221b1/1b6621daf5d78d73][http://bytes.com/topic/c-sharp/answers/439203-hashtable-items-order][http://stackoverflow.com/questions/1419708/how-to-keep-the-order-of-elements-in-hashtable][http://stackoverflow.com/questions/7105540/hashtable-values-reordered]
* Property enumeration order is unspecified in ECMAScript, yet all the major implementations have been forced to converge on insertion order, for compatibility with the Web as it is. There is, therefore, some concern that if TC39 does not specify a deterministic iteration order, “the web will just go and specify it for us”.[https://mail.mozilla.org/pipermail/es-discuss/2012-February/020576.html]
* Hash table iteration order can expose some bits of object hash codes. This imposes some astonishing security concerns on the hashing function implementer. For example, an object's address must not be recoverable from the exposed bits of its hash code. (Revealing object addresses to untrusted ECMAScript code, while not exploitable by itself, would be a bad security bug on the Web.)

Can a data structure retain the performance of traditional, arbitrary-order hash tables while also storing the order in which entries were added, so that iteration order is deterministic?

Tyler Close has developed a deterministic hash table that is structured like this (pseudocode):

struct Entry {
Key key;
Value value;
Entry *chain;
}

class CloseTable {
Entry*[] hashTable; // array of pointers into the data table
Entry[] dataTable;
}

Lookups and inserts proceed much like a bucket-and-chain hash table, but instead of each entry being allocated separately from the heap, they are stored in the <code>dataTable</code> in insertion order.

Removing an entry simply replaces its <code>key</code> with some sentinel while leaving the <code>chain</code> intact.

== Theory ==

'''Memory.''' Every map data structure must store the keys and values. A map with ''N'' entries must use at least ''NE'' memory, where ''E'' is the size of a key-value pair (we assume the data can’t be compressed).

In the following discussion we neglect the effect of deletions, which can cause both kinds of table to have extra memory that isn't in use at a given moment.

An open addressing hash table has additional overhead depending on the fill factor. <code>OpenTable</code> in particular has a maximum fill factor ''F''=3/4. When it becomes more than 3/4 full, it doubles in size, becoming just over 3/8 full. The amount of overhead in an <code>OpenTable</code> is ''(1/f)NE'', where ''f'' is the actual current fill ratio of the table and ''F/2 < f ≤ F''.

A Close table has three sources of overhead: the entire <code>hashTable</code>, the <code>chain</code> pointers in the <code>dataTable</code>, and the unused portion of the <code>dataTable</code>. In <code>CloseTable</code>, the <code>chain</code> pointer causes each entry to require ''(3/2)E'' memory rather than ''E''. The <code>dataTable</code> doubles in size when it becomes completely full, so its size is ''(3/2)(1/u)NE'' where ''u'' is the proportion of the <code>dataTable</code> that is in use and ''1/2 hashTable</code> is always 1/16 the size of the <code>dataTable</code> (1/8 on 64-bit platforms), so the total size of both tables is ''(1+1/16)(3/2)(1/u)NE'' (substitute 1/8 on 64-bit platforms).

For back-of-envelope purposes, then, ''f'' may be expected to be about ''3F/4'' (halfway between F/2 and F) and ''u'' about 3/4 on average; plugging these numbers in, we expect an <code>OpenTable</code> to have about (1/(3F/4))&times100%-100% = 78% memory overhead, and a <code>CloseTable</code> about 113% (125% on 64-bit), on average. This would mean that the <code>CloseTable</code> would be 20% larger on average (27% larger on 64-bit). However, see the Results section for a picture of how the two implementations compare in practice.

'''Speed.''' We consider the speed of lookups only. The <code>get</code>, <code>has</code>, <code>set</code>, and <code>delete</code> operations all start with a lookup. We will quantify the speed of lookups in terms of how many memory locations must be accessed. To simulate locality effects, we treat multiple reads from a single entry, or from the table object, as a single read.

In an open addressing hash table with fill factor ''f'', an unsuccessful lookup performs about ''1/(1-f)'' probes.[https://en.wikipedia.org/wiki/Hash_table#Performance_analysis] In an <code>OpenTable</code>, at worst ''f=F=3/4'' and so an unsuccessful lookup performs 4 probes on average. In the usual case, ''f=3F/4=9/16'', so about 2.3 probes on average.

<table class="data">
<tr>
<th rowspan=2>Data structure</th>
<th colspan=2>Expected cost of unsuccessful lookup (miss)</th>
<th colspan=2>Expected cost of successful lookup (hit)</th>
</tr>
<tr>
<th>Maximum load</th>
<th>Typical load</th>
<th>Maximum load</th>
<th>Typical load</th>
</tr>
<tr>
<td><code>OpenTable</code>
<td>5
<td>3.3
<td>-
<td>-
</tr>
<tr>
<td><code>CloseTable</code>
<td>-
<td>-
<td>-
<td>-
</tr>
</table>

= Method =

The code I used to make these pictures is available at: https://github.com/jorendorff/dht

The graphs below show data collected on a MacBook Pro, using g++-apple-4.2 and a 64-bit build. The results from running the test on a 32-bit Windows build were basically qualitatively the same. CloseTable performance was even better on Windows, for most tests; however, on LookupHitTest, OpenTable achieved almost equal speed.

The project contains two complete hash map implementations: OpenTable and CloseTable. A third implementation, DenseTable, is a thin wrapper around the <code>dense_hash_map</code> type from [https://code.google.com/p/sparsehash/ Sparsehash]. The three classes have the same API and were all benchmarked using the same templates (in hashbench.cpp).

Hash table implementation design notes:

* The API was designed to match the [http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets proposal for ECMAScript Map objects] as of February 2012.

* The Key and Value types are <code>uint64_t</code> because ECMAScript values are 64 bits in the implementation I'm most familiar with.

* OpenTable and CloseTable are meant to be as fast and as memory-efficient as possible. Pretty much everything that can be omitted was omitted. For example, the hashing function is trivial: ''hash(key) = key'', and neither OpenTable nor CloseTable further munges the hashcode before using it as a table index. Rationale: Making each implementation as fast as possible should highlight any performance difference between OpenTable and CloseTable, which is the purpose of the exercise. Using a more sophisticated hashing function would slow down both implementations, reducing the observed difference between the two techniques.

* DenseTable is provided as a baseline. (It's nice to have some realistic numbers in the graphs too.)

* dense_hash_map and OpenTable both implement straightforward hash tables with open addressing. The main difference between the two is one of tuning. dense_hash_map has a maximum load factor of 0.5. OpenTable has a maximum load factor of 0.75, which causes it to use about half as much memory most of the time.

* The purpose of the typedefs KeyArg and ValueArg is to make it possible to switch the API from pass-by-value to pass-by-reference by editing just a couple of lines of code. (I tried this. Pass-by-reference is no faster on 64-bit machines.)

* CloseTable attempts to allocate chunks of memory with sizes that are near powers of 2. This is to avoid wasting space when used with size-class-based malloc implementations.

* A Close table can trade some speed for compactness, but it seems to be a bad bargain:
** The load factor is adjustable. (The hash table size must remain at a power of two, but the data vector can have non-power-of-2 sizes.) However, increasing the load factor directly affects LookupMiss speed.
** An implementation could grow the data array by less than doubling it each time. I tried this. Insert speed suffered; lookup speed was unaffected; but the modified CloseTable still used more memory than OpenTable.

* <code>dense_hash_map</code> never shrinks the table unless you explicitly ask it to. <code>DenseTable::remove()</code> periodically shrinks, because otherwise, the performance on LookupAfterDeleteTest is pathologically bad.

Benchmark design notes:

* The benchmark is pure C++, rather than a Map/Set implementation embedded in an existing ES implementation, in order to make the results as stable as possible, to avoid biasing the results to a particular ES implementation, to encourage contributors, and to focus on the performance differences in the hash table implementations by eliminating all other performance effects as much as possible.

* The program runs each benchmark many different times in order to produce enough numbers that noise is visually obvious in the resulting graph. (Most of the speed graphs are nice and smooth.)

= Results =

== Memory usage ==

[[Image:jorendorff-dht-figure-1.png]]

All three implementations double the size of the table whenever it gets too full. On a log-log plot, this shows as stair-steps of a constant height. The slope of each staircase is 1, indicating linear growth.

Both OpenTable and CloseTable are much more memory-efficient than DenseTable, because <code>dense_hash_map</code> is tuned for fast lookups at all costs.

For any ''N'' > 5, a CloseTable with ''N'' entries allocates '''either 1.0625x or 2.125x as much memory''' as an OpenTable with ''N'' entries (1.125x or 2.25x as much memory on 64-bit systems). Both tables double in size at certain thresholds, and the thresholds for CloseTable are lower than those for OpenTable. That is, as a CloseTable is populated, it doubles in size sooner than the corresponding OpenTable. The factors determining this behavior are (1) the fact that CloseTable entries are 50% larger, and it therefore takes fewer of them to fill up a power-of-two-sized allocation; and (2) the value of <code>OpenTable::max_fill_factor()</code>.

It is tempting to reduce this complicated picture to a single number, and write that CloseTables are, for example, 20% larger. Or 30%. But such a number would not be easily justified mathematically: the ratio does not converge as the number of entries increases.

[[Image:jorendorff-dht-figure-2.png]]

DenseTable and OpenTable must initialize the entire table each time they resize. CloseTable also allocates large chunks of memory, but like a <code>vector</code>, it does not need to write to that memory until there is data that needs to be stored there.

This means that for a huge Map with no delete operations, a Close table could use more virtual memory but less physical memory than its open addressing counterparts. This will not be the only use case that stresses memory usage, though. Applications may also create many small tables and may delete entries from large tables.

== Insertion speed ==

[[Image:jorendorff-dht-InsertSmallTest-speed.png]]

This measures the time required to fill a table to about 100 entries, repeatedly. (The “1e7” on the axes indicates that the numbers are in tens of millions: the Close table is doing about 60 million inserts per second on this machine.)

This graph and the following ones show speed, so '''higher is better'''.

Ideally all these graphs would show three straight horizontal lines, indicating that all three implementations scale beautifully to large work loads. And indeed this seems to be the case, mostly.

[[Image:jorendorff-dht-InsertLargeTest-speed.png]]

This test measures the time required to fill a single gigantic table.

The jagged shape of this graph is robust. It reflects the fact that the table doubles in size as it grows, and rehashing is a significant part of the expense of populating a huge table.

== Lookup speed ==

[[Image:jorendorff-dht-LookupHitTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where ''k'' is the key of an existing entry in the table.

[[Image:jorendorff-dht-LookupMissTest-speed.png]]

This test measures the speed of <code>table.get(k)</code> operations, where the key ''k'' is not found in the table.

In an OpenTable, lookups that miss are slower than lookups that hit ''when there is at least one collision''. This is because we keep probing the hash table until we find an empty entry.

DenseTable is only slightly slower for misses, perhaps because more lookups have zero collisions. (?)

== Deletion speed ==

[[Image:jorendorff-dht-WorklistTest-speed.png]]

This test creates a table with 700 entries, then measures the speed of alternately adding an entry and deleting the oldest remaining entry from the table. Entries are therefore removed in FIFO order. Each “operation” here includes both an insert and a delete.

The CloseTable stores the entries in insertion order, so this test gets extremely good memory locality. The effect is even more pronounced in a 32-bit build.

[[Image:jorendorff-dht-DeleteTest-speed.png]]

This test measures the speed of deleting all entries from a very large table.

The numbers for dense_hash_map are jagged because <code>DenseMap</code> shrinks the table at certain threshold sizes as entries are deleted, and shrinking the table is expensive.

The apparent randomness of the OpenTable and CloseTable numbers is reproducible and unexplained.

[[Image:jorendorff-dht-LookupAfterDeleteTest-speed.png]]

This test measures the performance of lookups, mostly misses, in a table that was filled to size 50000, then reduced to size 195 by deleting most of the entries.

The results here are sensitive to the two sizes, which are totally arbitrary choices. A less arbitrary replacement for this test would be welcome.